From robla at real.com  Fri Oct  1 01:24:56 2004
From: robla at real.com (Rob Lanphier)
Date: Fri Oct  1 01:25:58 2004
Subject: [Mailman-Developers] Pickle-induced integration issues
Message-ID: <1096586696.4615.51.camel@localhost.localdomain>

Hi folks,

I manage Helix Community, which makes pretty heavy use of Mailman as
integrated into GForge.  I'm moderately familiar with Mailman code, and
pretty familiar with GForge.  Of course, Perl is my native tongue, so
I'm equally uncomfortable in both codebases  ;-)

Anyway, one thing that my users are constantly clamoring for is features
that would come from tighter integration between GForge and Mailman.
I've been mulling this over for a while, and it seems that deep
integration is limited by the way that most Mailman data is stored in
pickles.  Since GForge is coded and pretty heavily bound to PHP.

My options for integration between the two seem to be:
1.  Implement alternate GForge authentication mechanism in Mailman 
2.  Implement alternate, PHP-compatible storage mechanism (e.g. SQL
database) for everything currently stored in pickles
3.  Implement pickle support in PHP
4.  Implement IPC mechanism (e.g. SOAP, XML-RPC) as a Mailman control
daemon, and call that from GForge

I'm wondering if there are recommendations from this group.  I'm also
wondering if there have been any movements/efforts in any of these
directions already.

This is one of many problems that I plan to work on over time, and plan
to contribute patches to the extent that they are useful to a larger
community.  If I'm lucky, I'll get budget to hire developers for this,
but for now, I'll be doing this on the cheap.

Thoughts?
Rob
-- 
Rob Lanphier, Development Support Manager - RealNetworks
Helix Community: http://helixcommunity.org 
Development Support:
http://www.realnetworks.com/products/support/devsupport

From barry at python.org  Fri Oct  1 02:20:48 2004
From: barry at python.org (Barry Warsaw)
Date: Fri Oct  1 02:20:52 2004
Subject: [Mailman-Developers] Pickle-induced integration issues
In-Reply-To: <1096586696.4615.51.camel@localhost.localdomain>
References: <1096586696.4615.51.camel@localhost.localdomain>
Message-ID: <1096590048.20270.160.camel@geddy.wooz.org>

On Thu, 2004-09-30 at 19:24, Rob Lanphier wrote:

> Anyway, one thing that my users are constantly clamoring for is features
> that would come from tighter integration between GForge and Mailman.
> I've been mulling this over for a while, and it seems that deep
> integration is limited by the way that most Mailman data is stored in
> pickles.  Since GForge is coded and pretty heavily bound to PHP.

Do you care about list data, user data, or both?

If it's user data, then you can mostly write a backend for the
MemberAdaptor interface that shoves the data into whatever GForge uses. 
If it's list data you want to integrate, that's harder <wink>.

> I'm wondering if there are recommendations from this group.  I'm also
> wondering if there have been any movements/efforts in any of these
> directions already.

This is what MM3 is all about.  Every piece of data will be stored in a
backend through an interface, including messages, user data, and list
data.  MM3 will come with some persistent database on the backend by
default, but I hope/envision/expect that there will be backends for
other databases (e.g. MySQL, LDAP, etc.).

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20040930/93f311a5/attachment.pgp
From brad at stop.mail-abuse.org  Fri Oct  1 02:34:31 2004
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Fri Oct  1 02:34:37 2004
Subject: [Mailman-Developers] Pickle-induced integration issues
In-Reply-To: <1096586696.4615.51.camel@localhost.localdomain>
References: <1096586696.4615.51.camel@localhost.localdomain>
Message-ID: <p06002014bd82561febfb@[10.0.1.3]>

At 4:24 PM -0700 2004-09-30, Rob Lanphier wrote:

>  Anyway, one thing that my users are constantly clamoring for is features
>  that would come from tighter integration between GForge and Mailman.
>  I've been mulling this over for a while, and it seems that deep
>  integration is limited by the way that most Mailman data is stored in
>  pickles.  Since GForge is coded and pretty heavily bound to PHP.

	See <http://www.list.org/devs.html>.  In particular:

		Mailman uses an inefficient persistency system based on
		Python pickles, and every mailing list has its own pickled
		state. This has several disadvantages, including poor
		scalability, difficulty in doing cross-mailing list
		operations, and the virtual host limitation on list names.
		Mailman 3.0 will use a real database, perhaps based on ZODB
		or BerkeleyDB. Again, the goal is to generalize the
		interface to the backend database so that others can be
		used, but choose one and ship it by default.

>  I'm wondering if there are recommendations from this group.  I'm also
>  wondering if there have been any movements/efforts in any of these
>  directions already.
>
>  This is one of many problems that I plan to work on over time, and plan
>  to contribute patches to the extent that they are useful to a larger
>  community.  If I'm lucky, I'll get budget to hire developers for this,
>  but for now, I'll be doing this on the cheap.

	You could funnel your work into Mailman3, and if you could get 
some budget to make that happen, then the project will be able to be 
shipped that much faster.

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

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

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

   SAGE member since 1995.  See <http://www.sage.org/> for more info.
From robla at real.com  Fri Oct  1 02:58:44 2004
From: robla at real.com (Rob Lanphier)
Date: Fri Oct  1 02:59:47 2004
Subject: [Mailman-Developers] Pickle-induced integration issues
In-Reply-To: <p06002014bd82561febfb@[10.0.1.3]>
References: <1096586696.4615.51.camel@localhost.localdomain>
	<p06002014bd82561febfb@[10.0.1.3]>
Message-ID: <1096592324.4615.59.camel@localhost.localdomain>

On Fri, 2004-10-01 at 02:34 +0200, Brad Knowles wrote:
> 	See <http://www.list.org/devs.html>.  In particular:
> 
> 		Mailman uses an inefficient persistency system based on
> 		Python pickles, and every mailing list has its own pickled
> 		state. This has several disadvantages, including poor
> 		scalability, difficulty in doing cross-mailing list
> 		operations, and the virtual host limitation on list names.
> 		Mailman 3.0 will use a real database, perhaps based on ZODB
> 		or BerkeleyDB. Again, the goal is to generalize the
> 		interface to the backend database so that others can be
> 		used, but choose one and ship it by default.

Ah, very cool.  Thanks Brad and Barry for your quick answers.  I'll look
through the MM3 plans, and hopefully I'll be able to contribute a
little.

I'm somewhat tempted to knock something out quick and dirty based on the
MemberAdapter work, but by the time I get around to doing something like
that, MM3 will probably be a lot closer to reality.  I'll also post
something on helixcommunity.org.  Since many of the people complaining
are competent developers, maybe I can enlist them  ;-)

Rob
-- 
Rob Lanphier, Development Support Manager - RealNetworks
Helix Community: http://helixcommunity.org 
Development Support:
http://www.realnetworks.com/products/support/devsupport

From andyk at spunge.org  Fri Oct  1 17:27:44 2004
From: andyk at spunge.org (Andrzej Kasperowicz)
Date: Fri Oct  1 17:57:15 2004
Subject: [Mailman-Developers] How to change comment sent by Mailman with
	rejected posts?
Message-ID: <Pine.LNX.4.58.0410011027040.10956@chi.spunge.org>

When in Content filtering Section I set Reject as Action to take when a
message matches the content filtering rules, then the sender of the message,
which was rejected, receives the following e-mail from Mailman:
"The message's content type was not explicitly allowed"

How could I change that message? Is there any form where I could put new text
of the message, and if there is no form, could you please add it in future
version of Mailman?

ak

From andyk at spunge.org  Fri Oct  1 17:28:12 2004
From: andyk at spunge.org (Andrzej Kasperowicz)
Date: Fri Oct  1 17:57:16 2004
Subject: [Mailman-Developers] Content-filtering - is filtering of
	content-description possible?
Message-ID: <Pine.LNX.4.58.0410011027470.10956@chi.spunge.org>

Is in the Content filtering section possible to define only content-type?
I suggest that it should be also possible to define Content-description.
Because Pegasus Mail for example when is sending an attachment it adds
content-descriprion, and mailman filter although removes the attachment
itself, it does not remove the content-describtion causing to send to the list
a message with the following text content:

-------------- next part --------------
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

   ---- File information -----------
     File:  1.jpg
     Date:  1 Oct 2004, 13:37
     Size:  8500 bytes.
     Type:  JPEG-image

==========

Header of that message shows:
--Message-Boundary-14246
Content-type: text/plain; charset=US-ASCII
Content-disposition: inline
Content-description: Attachment information.

so if a content-description could be added to mailman content filtering
section then I could remove it as well.

ak

From wheakory at isu.edu  Fri Oct  1 18:53:25 2004
From: wheakory at isu.edu (Kory Wheatley)
Date: Fri Oct  1 18:54:07 2004
Subject: [Mailman-Developers] Attachments directory
Message-ID: <415D8B85.6010409@isu.edu>

Question for all of you, I added the addition below code into the 
Scrubber.py script, and the filename extensions are used has specified 
and not changed, so that works.
But when I go and view a Microsoft Word or Microsoft Excel scrubbed 
document in the archives it will not bring up the right plugins and 
displays garbled characters and lines in the browser window.  I know for 
a fact that I have the correct mime types specified on the Apache Web 
server.
Now, here's where it gets strange, I can move that attachment word file 
out of the "/archives/private/mlist/attachments" directory and put it in 
another Mailman directory on the web server, and it will bring up the 
Microsoft Word or Excel plugin and display the document fine.  The mime 
types I thought should be global on the web server, unless you have 
.htaccess file where you want to change the content type for that 
extension, which I don't see in the "attachments" directory.  Any idea 
whats going on?

+    # i18n file name is encoded

+    lcset = Utils.GetCharSet(mlist.preferred_language)

+    filename = Utils.oneline(msg.get_filename(''), lcset)

+    fnext = os.path.splitext(filename)[1]

+    # For safety, we should confirm this is valid ext for content-type

+    # but we can use fnext if we introduce fnext filtering

+    if mm_cfg.SCRUBBER_USE_ATTACHMENT_FILENAME_EXTENSION:

+        ext = fnext

+    else:

+        ext = guess_extension(ctype, fnext)

     if not ext:

         # We don't know what it is, so assume it's just a shapeless

         # application/octet-stream, unless the Content-Type: is



With this patch, site manager can set

SCRUBBER_USE_ATTACHMENT_FILENAME_EXTENSION = True

in mm_cfg.py to use attachment filename extension as is specified by

the original attachment. I also want to merge patch id 1027882

so that really dangerous files can be trapped by MimeDel.py.


-- 
Kory Wheatley
Academic Computing Analyst Sr.
Phone 282-3874
#########################################
Everything must point to him.

From gustavorfranco at gmail.com  Fri Oct  1 19:23:33 2004
From: gustavorfranco at gmail.com (Gustavo Franco)
Date: Fri Oct  1 19:23:38 2004
Subject: [Mailman-Developers] Re: Limiting numbers of members per list.
In-Reply-To: <5fabd6fd04092013242240a1ab@mail.gmail.com>
References: <5fabd6fd04092013242240a1ab@mail.gmail.com>
Message-ID: <5fabd6fd0410011023167a3cbd@mail.gmail.com>

Hi list,

I've a updated patch and with this one you can limit the number of
members per list not only using the change_maxmembers script but with
'create' (web interface) script too.

Can anyone review it? I'm really interested in this feature and i want
to improve this patch.

It's the patch #1029275 at sf.net project page.

Hope that helps,
Gustavo Franco
Information Network for the Third Sector
http://www.rits.org.br
-------------- next part --------------
A non-text attachment was scrubbed...
Name: memberslimit-v2.patch
Type: application/x-httpd-php
Size: 13236 bytes
Desc: not available
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20041001/36ba449b/memberslimit-v2.pht
From tkikuchi at is.kochi-u.ac.jp  Sat Oct  2 02:58:34 2004
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Sat Oct  2 02:59:02 2004
Subject: [Mailman-Developers] Attachments directory
In-Reply-To: <415D8B85.6010409@isu.edu>
References: <415D8B85.6010409@isu.edu>
Message-ID: <415DFD3A.1020801@is.kochi-u.ac.jp>

Hi. I was away from office this week. ;-)

Kory Wheatley wrote:

> But when I go and view a Microsoft Word or Microsoft Excel scrubbed 
> document in the archives it will not bring up the right plugins and 
> displays garbled characters and lines in the browser window.  I know for 
> a fact that I have the correct mime types specified on the Apache Web 
> server.

You should check <apache-install-dir>/conf/httpd.conf also.
My suggestion is to set
DefaultType application/octet-stream

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

From stephen at xemacs.org  Mon Oct  4 07:52:32 2004
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon Oct  4 07:55:43 2004
Subject: [Mailman-Developers] SCRUBBER Question
In-Reply-To: <415560A6.6010103@is.kochi-u.ac.jp> (Tokio Kikuchi's message of
	"Sat, 25 Sep 2004 21:12:22 +0900")
References: <ACB4F388-0E72-11D9-ABA9-00039383CAAE@terc.edu>
	<415560A6.6010103@is.kochi-u.ac.jp>
Message-ID: <87brfj6ndr.fsf@tleepslib.sk.tsukuba.ac.jp>

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

    Tokio> I think I should commit one of my unpublishd patch on
    Tokio> SourceForge CVS.

[...]

    Tokio> With this patch, site manager can set
    Tokio> SCRUBBER_USE_ATTACHMENT_FILENAME_EXTENSION = True in
    Tokio> mm_cfg.py to use attachment filename extension as is
    Tokio> specified by the original attachment.

Arrgh.  A couple of my lists share a host with people who would
probably like to have that option = True, but I definitely want False.
Can this be made to be a "site manager permits, list manager enables"
double opt-in option, pretty please?

BTW, don't serious webservers support some kind of ./.htmime.types
facility?  If so, then the archiver could inform the webserver of the
MIME type it observed for the file, and pretty much wash its hands of
the issue.  (You'd still like to tell the webserver that the file came
from a poorly authenticated source, but I think for directories
containing list archives you can normally just assume that. ;-)

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.
From stephen at xemacs.org  Mon Oct  4 08:22:08 2004
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon Oct  4 08:22:21 2004
Subject: [Mailman-Developers] in-reply-to problem
In-Reply-To: <p0600202abd80474c6df1@[10.0.1.4]> (Brad Knowles's message of
	"Wed, 29 Sep 2004 13:06:55 +0200")
References: <415956AB.1080704@cybernetsoft.com>
	<p0600201bbd7f22b2d9d6@[10.0.1.4]> <415A48C9.60803@cybernetsoft.com>
	<p0600202abd80474c6df1@[10.0.1.4]>
Message-ID: <877jq76m0f.fsf@tleepslib.sk.tsukuba.ac.jp>

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

    Brad> 	You could spend a trillion dollars on this problem and
    Brad> not find a solution.  The entire computer industry has been
    Brad> working on AI since the early 1960s, and they haven't solve
    Brad> it yet, and don't appear to be much closer today than they
    Brad> were back then.

That's a bit pessimistic, don't you think?  What can be done without
I-R-T or References doesn't require AI.  Plenty of MUAs solve the
problem of threading messages with no I-R-T header satisfactorily (ie,
messages that are in the same thread almost always appear within a few
lines of each other in the summary).

K.S., the problem here is that threading algorithms require data about
the other messages in the thread.  Mailman handles messages _one at a
time_, and does not have the information about other messages
(specifically dates and subjects) needed to guess at threading.  So
forget about hacking Mailman; you'd kill performance, most likely.

On the other hand, an archiver (such as Pipermail, distributed with
Mailman, or MHonArc, a popular third-party archiver) does (typically)
have that information, at least in "rebuild-the-whole-shebang" mode,
and I would say that you should look at archivers, not at Mailman
proper.  Also look in the mailman FAQ for how to use a 3rd-party
archiver with Mailman; you can probably find one that does a better
job than Pipermail does.  MHonArc would be a good bet.

http://www.jwz.org/doc/threading.html describes a threading algorithm
that is fairly robust to this problem in my limited experience with it

That's as far as I'm willing to go though.  Really, you should get
your users to switch to an MUA that can handle headers that were
standardized in 1975 or so.  And there are plenty of MUAs that can do
something sane about pseudo-threading messages without I-R-T.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.
From brad at stop.mail-abuse.org  Mon Oct  4 10:27:42 2004
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Mon Oct  4 10:34:39 2004
Subject: [Mailman-Developers] in-reply-to problem
In-Reply-To: <877jq76m0f.fsf@tleepslib.sk.tsukuba.ac.jp>
References: <415956AB.1080704@cybernetsoft.com>
	<p0600201bbd7f22b2d9d6@[10.0.1.4]>
	<415A48C9.60803@cybernetsoft.com>
	<p0600202abd80474c6df1@[10.0.1.4]>
	<877jq76m0f.fsf@tleepslib.sk.tsukuba.ac.jp>
Message-ID: <p06002000bd86b8fc9815@[10.0.1.5]>

At 3:22 PM +0900 2004-10-04, Stephen J. Turnbull wrote:

>>>>>>  "Brad" == Brad Knowles <brad@stop.mail-abuse.org> writes:
>
>      Brad> 	You could spend a trillion dollars on this problem and
>      Brad> not find a solution.  The entire computer industry has been
>      Brad> working on AI since the early 1960s, and they haven't solve
>      Brad> it yet, and don't appear to be much closer today than they
>      Brad> were back then.
>
>  That's a bit pessimistic, don't you think?  What can be done without
>  I-R-T or References doesn't require AI.  Plenty of MUAs solve the
>  problem of threading messages with no I-R-T header satisfactorily (ie,
>  messages that are in the same thread almost always appear within a few
>  lines of each other in the summary).

	I don't think I'm being pessimistic here.  I think I'm being 
realistic.  There are no deterministic ways to figure out precisely 
which message is being replied to and which other messages are being 
referenced, unless you can guarantee that you can perfectly parse all 
possible quoting methods, and you can guarantee that you will always 
have enough information available in the quote to guarantee that you 
can determine which message is which.

	Unfortunately, in the real world, you can't guarantee any of those things.

>  On the other hand, an archiver (such as Pipermail, distributed with
>  Mailman, or MHonArc, a popular third-party archiver) does (typically)
>  have that information, at least in "rebuild-the-whole-shebang" mode,
>  and I would say that you should look at archivers, not at Mailman
>  proper.  Also look in the mailman FAQ for how to use a 3rd-party
>  archiver with Mailman; you can probably find one that does a better
>  job than Pipermail does.  MHonArc would be a good bet.

	In terms of re-creating threading data that was destroyed by an 
the MUA?  No, I don't think that you're going to find much here.

>  http://www.jwz.org/doc/threading.html describes a threading algorithm
>  that is fairly robust to this problem in my limited experience with it

	Right, and as complex as this algorithm is, it still requires 
"In-Reply-To:" and "References:" headers in order to be able to do 
it's job.

>  That's as far as I'm willing to go though.  Really, you should get
>  your users to switch to an MUA that can handle headers that were
>  standardized in 1975 or so.  And there are plenty of MUAs that can do
>  something sane about pseudo-threading messages without I-R-T.

	Now there's a statement that I can agree with.

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

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

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

   SAGE member since 1995.  See <http://www.sage.org/> for more info.
From patrick at med.cuhk.edu.hk  Mon Oct  4 11:05:53 2004
From: patrick at med.cuhk.edu.hk (Patrick Lam)
Date: Mon Oct  4 11:06:05 2004
Subject: [Mailman-Developers] Rewrite the email header to hide the "To"
	address
Message-ID: <200410040905.i9495wl30940@ruby.med.cuhk.edu.hk>

Dear Experts,

 

            Is there any option (or change a small part of code) in Mailman
that allow us to rewrite the "To" field, say "Undisclosed-recipients" so
that the name of the mailing list will not be exposed to the recipients???
Actually, I am using Mailman for email distribution and receive a lot of
virus emails as some of the recipients' machine is infected.  I knew BCC can
help, however, just afraid the users will forget .

 

            Million thanks!!

 

 

Regards,

Patrick

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

Patrick Lam Sze Fan

Computer Officer II

Medical Information Technology,

Faculty of Medicine,

The Chinese University of Hong Kong

Tel:21455213   Fax:26375470

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

 

From tkikuchi at is.kochi-u.ac.jp  Mon Oct  4 15:04:09 2004
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Mon Oct  4 15:04:30 2004
Subject: [Mailman-Developers] SCRUBBER Question
In-Reply-To: <415560A6.6010103@is.kochi-u.ac.jp>
References: <ACB4F388-0E72-11D9-ABA9-00039383CAAE@terc.edu>
	<415560A6.6010103@is.kochi-u.ac.jp>
Message-ID: <41614A49.6050208@is.kochi-u.ac.jp>


> I think I should commit one of my unpublishd patch on SourceForge CVS.
(snip)
> With this patch, site manager can set
> SCRUBBER_USE_ATTACHMENT_FILENAME_EXTENSION = True
> in mm_cfg.py to use attachment filename extension as is specified by
> the original attachment. I also want to merge patch id 1027882
> so that really dangerous files can be trapped by MimeDel.py.

I've committed these patches in the cvs.
You can download the latest source from the cvs by:
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/mailman co \
  -r Release_2_1-maint mailman

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

From tkikuchi at is.kochi-u.ac.jp  Mon Oct  4 15:10:02 2004
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Mon Oct  4 15:10:17 2004
Subject: [Mailman-Developers] SCRUBBER Question
In-Reply-To: <87brfj6ndr.fsf@tleepslib.sk.tsukuba.ac.jp>
References: <ACB4F388-0E72-11D9-ABA9-00039383CAAE@terc.edu>	<415560A6.6010103@is.kochi-u.ac.jp>
	<87brfj6ndr.fsf@tleepslib.sk.tsukuba.ac.jp>
Message-ID: <41614BAA.8080003@is.kochi-u.ac.jp>

Hi,

Stephen J. Turnbull wrote:

> Arrgh.  A couple of my lists share a host with people who would
> probably like to have that option = True, but I definitely want False.
> Can this be made to be a "site manager permits, list manager enables"
> double opt-in option, pretty please?

Please submit an item in SourceForge feature request (RFE) tracker. I 
have no time to work on this now but may be able to tackle near future.
http://sourceforge.net/tracker/?group_id=103&atid=350103

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

From wheakory at isu.edu  Mon Oct  4 20:03:47 2004
From: wheakory at isu.edu (Kory Wheatley)
Date: Mon Oct  4 20:09:19 2004
Subject: [Mailman-Developers] Attachments directory
In-Reply-To: <415DFD3A.1020801@is.kochi-u.ac.jp>
References: <415D8B85.6010409@isu.edu> <415DFD3A.1020801@is.kochi-u.ac.jp>
Message-ID: <41619083.3020204@isu.edu>

Actually I've already tried this, whats weird is I can move this 
attachment out of this directory and it will bring up the right plugin.  
I haven't ever seen anything like this before.

Tokio Kikuchi wrote:

> Hi. I was away from office this week. ;-)
>
> Kory Wheatley wrote:
>
>> But when I go and view a Microsoft Word or Microsoft Excel scrubbed 
>> document in the archives it will not bring up the right plugins and 
>> displays garbled characters and lines in the browser window.  I know 
>> for a fact that I have the correct mime types specified on the Apache 
>> Web server.
>
>
> You should check <apache-install-dir>/conf/httpd.conf also.
> My suggestion is to set
> DefaultType application/octet-stream
>
> Cheers,


-- 
Kory Wheatley
Academic Computing Analyst Sr.
Phone 282-3874
#########################################
Everything must point to him.

From stephen at xemacs.org  Tue Oct  5 11:25:55 2004
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue Oct  5 11:25:59 2004
Subject: [Mailman-Developers] in-reply-to problem
In-Reply-To: <p06002000bd86b8fc9815@[10.0.1.5]> (Brad Knowles's message of
	"Mon, 4 Oct 2004 10:27:42 +0200")
References: <415956AB.1080704@cybernetsoft.com>
	<p0600201bbd7f22b2d9d6@[10.0.1.4]> <415A48C9.60803@cybernetsoft.com>
	<p0600202abd80474c6df1@[10.0.1.4]>
	<877jq76m0f.fsf@tleepslib.sk.tsukuba.ac.jp>
	<p06002000bd86b8fc9815@[10.0.1.5]>
Message-ID: <87hdp94iu4.fsf@tleepslib.sk.tsukuba.ac.jp>

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

	I don't think I'm being pessimistic here.  I think I'm being
	realistic.  There are no deterministic ways to figure out
	precisely which message is being replied to and which other
	messages are being referenced, unless you can guarantee that
	you can perfectly parse all possible quoting methods,

Oh, I admit that.  I just suspect that for the OP (1) grouping
subjects and (2) never violating Date order will typically result in a
Summary display that's "good enough".

If he wants to go so far as parsing quoting, well, I've written such
code and it was a dismal failure (ie, it did not improve visibly over
sorting by subject and date).  Doesn't mean it can't be done, by a
long shot ;-), but I would suggest it's cheaper to hire a moderator to
do the rethreading.

    Brad> 	Right, and as complex as [jwz's] algorithm is, it still
    Brad> requires "In-Reply-To:" and "References:" headers in order
    Brad> to be able to do it's job.

Actually, the complex part is all about ensuring that the true
threading operations are stable with respect to the subject/date
sort.  This is something that Gnus (for example) gets wrong.  I'd much
rather read a newsgroup with Gnus than Netscape 3 (I think it was),
but Netscape 3 did a far better job with mailing lists that lacked
true threading information.


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.
From kl at vsen.dk  Wed Oct  6 12:25:11 2004
From: kl at vsen.dk (Klavs Klavsen)
Date: Wed Oct  6 12:22:28 2004
Subject: [Mailman-Developers] bug in danish translation - which line?
Message-ID: <4163C807.4070908@vsen.dk>

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

Hi guys,

There's a bug in the danish translation somewhere :(

I get an error when trying to unsubscribe at this address (only when
page is shown in danish):
http://www.linuxpusher.dk/mailman/listinfo/linuxpusher-nyhedsbrev

The error is:
Traceback (most recent call last):
~  File "/usr/local/mailman/scripts/driver", line 87, in run_main
~    main()
~  File "/usr/local/mailman/Mailman/Cgi/options.py", line 239, in main
~    loginpage(mlist, doc, user, language)
~  File "/usr/local/mailman/Mailman/Cgi/options.py", line 813, in loginpage
~    table.AddRow([_("""In order to change your membership option, you must
~  File "/usr/local/mailman/Mailman/i18n.py", line 89, in _
~    return tns % dict
ValueError: unsupported format character 'p' (0x70) at index 105

how do I figure out the place in the mailman.po file where the problem
is (which is where I suppose the problem must be?)?
- --
Regards,
Klavs Klavsen, GSEC - kl@vsen.dk - http://www.vsen.dk
PGP: 7E063C62/2873 188C 968E 600D D8F8  B8DA 3D3A 0B79 7E06 3C62

"Those who do not understand Unix are condemned to reinvent it, poorly."
~  --Henry Spencer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBY8gHPToLeX4GPGIRAn7OAJ4hN9Y5OqU2cqFN+0VvTSHWEg2CAQCgg0Qx
RWyNyAWyy/fhxMnBW7Xe/3s=
=Zt41
-----END PGP SIGNATURE-----
From jwt at OnJapan.net  Wed Oct  6 14:27:06 2004
From: jwt at OnJapan.net (Jim Tittsler)
Date: Wed Oct  6 14:26:11 2004
Subject: [Mailman-Developers] bug in danish translation - which line?
In-Reply-To: <4163C807.4070908@vsen.dk>
References: <4163C807.4070908@vsen.dk>
Message-ID: <20041006122706.GE19452@server.onjapan.net>

On Wed, Oct 06, 2004 at 12:25:11PM +0200, Klavs Klavsen wrote:
> There's a bug in the danish translation somewhere :(

http://mail.python.org/pipermail/mailman-users/2004-August/038622.html

> how do I figure out the place in the mailman.po file where the problem
> is (which is where I suppose the problem must be?)?

The patch is above.  (It's been reported to the Danish language
champion.  I expect it will be fixed by the next release.)

-- 
Jim Tittsler             http://www.OnJapan.net/      GPG: 0x01159DB6
Python Starship          http://Starship.Python.net/
Ringo MUG Tokyo          http://www.ringo.net/rss.html

From tkikuchi at is.kochi-u.ac.jp  Wed Oct  6 15:17:39 2004
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Wed Oct  6 15:17:58 2004
Subject: [Mailman-Developers] bug in danish translation - which line?
In-Reply-To: <20041006122706.GE19452@server.onjapan.net>
References: <4163C807.4070908@vsen.dk>
	<20041006122706.GE19452@server.onjapan.net>
Message-ID: <4163F073.9060807@is.kochi-u.ac.jp>

Hi,

Jim Tittsler wrote:

> On Wed, Oct 06, 2004 at 12:25:11PM +0200, Klavs Klavsen wrote:
> 
>>There's a bug in the danish translation somewhere :(
> 
> 
> http://mail.python.org/pipermail/mailman-users/2004-August/038622.html
> 
> 
>>how do I figure out the place in the mailman.po file where the problem
>>is (which is where I suppose the problem must be?)?
> 
> 
> The patch is above.  (It's been reported to the Danish language
> champion.  I expect it will be fixed by the next release.)
> 

I've commited the patch in the CVS. You can download the latest CVS from 
  SourceForge. (though it may take a short time for the anonymous cvs to 
be updated.)

Cheers,

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

From jdennis at redhat.com  Wed Oct  6 20:39:38 2004
From: jdennis at redhat.com (John Dennis)
Date: Wed Oct  6 20:39:40 2004
Subject: [Mailman-Developers] make finish?
Message-ID: <1097087977.32497.22.camel@finch.boston.redhat.com>

As part of our effort to make our mailman installation FHS compliant
I've been going through the "make install" and check_perms process with
a fine tooth comb looking for any discrepancies and discovered some
installation anomalies in the virgin 2.1.5 tarball, but more on that
later... In the meantime I wanted to ask a specific question.

In the mailman-2.1.5/src/Makefile.in are commands to change the owner &
permissions on $prefix/cgi-bin/private. The owner is changed to
MAILMAN_USER with setuid permission.

The problem is this part of the install never executes. Why? Its part of
the "finish" make target and finish is not a dependency of anything.
Most all the Makefiles have a finish target which are empty, only
src/Makefile.in actually does something for the finish target.

Is this Makefile cruft or should this be executed? Note that
mailman-2.1.5/Makefile.in removes the "other" read permission on
$prefix/archives/private, but it leaves group read/write. This suggests
to me that $prefix/cgi-bin/private with setgid and arbitrary owner (e.g.
without running the "finish") is fine and thus leads me to the
conclusion the finish target is cruft.

Is this right?
-- 
John Dennis <jdennis@redhat.com>

From barry at python.org  Wed Oct  6 21:42:05 2004
From: barry at python.org (Barry Warsaw)
Date: Wed Oct  6 21:42:10 2004
Subject: [Mailman-Developers] make finish?
In-Reply-To: <1097087977.32497.22.camel@finch.boston.redhat.com>
References: <1097087977.32497.22.camel@finch.boston.redhat.com>
Message-ID: <1097091725.20139.28.camel@geddy.wooz.org>

On Wed, 2004-10-06 at 14:39, John Dennis wrote:

> Is this Makefile cruft or should this be executed? Note that
> mailman-2.1.5/Makefile.in removes the "other" read permission on
> $prefix/archives/private, but it leaves group read/write. This suggests
> to me that $prefix/cgi-bin/private with setgid and arbitrary owner (e.g.
> without running the "finish") is fine and thus leads me to the
> conclusion the finish target is cruft.
> 
> Is this right?

Yes.  I don't remember why "make finish" was added, but it's probably
cruft left over from when it was possible to run MM2 from the source
directory.  I briefly skimmed the CVS logs, but they didn't provide much
of a clue.

All the 'finish' targets can probably be ignored or removed.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20041006/80d64df4/attachment.pgp
From tkikuchi at is.kochi-u.ac.jp  Mon Oct 11 02:32:28 2004
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Mon Oct 11 02:32:49 2004
Subject: [Mailman-Developers] referring fix_url.py
Message-ID: <4169D49C.8090400@is.kochi-u.ac.jp>

Hi developers,

Since there are so many questions on 'how to fix exsiting list url',
I want to add comments on fix_url.py in the ditribution documents.
I am not a native english writer, so can someone fix my patch?

TIA

Tokio


Index: INSTALL
===================================================================
--- INSTALL	(.../trunk)	(revision 68)
+++ INSTALL	(.../branches/test_branch)	(revision 68)
@@ -435,7 +435,10 @@

            add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)

+      Note that you may also want to run bin/fix_url.py to change
+      existing lists' domain.

+
  5. Customize Mailman

      You should do these steps using the account you installed Mailman
Index: Mailman/Defaults.py.in
===================================================================
--- Mailman/Defaults.py.in	(.../trunk)	(revision 68)
+++ Mailman/Defaults.py.in	(.../branches/test_branch)	(revision 68)
@@ -137,6 +137,8 @@
  # VIRTUAL_HOST['www.dom.ain']
  # ==> 'dom.ain'
  #
+# Note also that you have to run bin/fix_url.py if you want to change 
existing
+# lists' domain. Read the help output from the script for detail.
  def add_virtualhost(urlhost, emailhost=None):
      DOT = '.'
      if emailhost is None:



From barry at python.org  Mon Oct 11 04:24:32 2004
From: barry at python.org (Barry Warsaw)
Date: Mon Oct 11 04:24:45 2004
Subject: [Mailman-Developers] referring fix_url.py
In-Reply-To: <4169D49C.8090400@is.kochi-u.ac.jp>
References: <4169D49C.8090400@is.kochi-u.ac.jp>
Message-ID: <1097461472.8123.8.camel@geddy.wooz.org>

On Sun, 2004-10-10 at 20:32, Tokio Kikuchi wrote:

> +      Note that you may also want to run bin/fix_url.py to change
> +      existing lists' domain.

I'd probably word it like this: "Note that you will want to run
bin/fix_url.py to change the domain of an existing list.  bin/fix_url.py
must be run within the bin/withlist script.

-Barry

P.S. Thanks so much for all the patches!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20041010/728703ce/attachment.pgp
From jrhett at meer.net  Mon Oct 11 07:31:03 2004
From: jrhett at meer.net (Joe Rhett)
Date: Mon Oct 11 07:32:09 2004
Subject: [Mailman-Developers] referring fix_url.py
In-Reply-To: <1097461472.8123.8.camel@geddy.wooz.org>
References: <4169D49C.8090400@is.kochi-u.ac.jp>
	<1097461472.8123.8.camel@geddy.wooz.org>
Message-ID: <20041011053103.GB92312@meer.net>

On Sun, Oct 10, 2004 at 10:24:32PM -0400, Barry Warsaw wrote:
> On Sun, 2004-10-10 at 20:32, Tokio Kikuchi wrote:
> 
> > +      Note that you may also want to run bin/fix_url.py to change
> > +      existing lists' domain.
> 
> I'd probably word it like this: "Note that you will want to run
> bin/fix_url.py to change the domain of an existing list.  bin/fix_url.py
> must be run within the bin/withlist script.
 
What does "within the bin/withlist script" mean?  Sorry, rhetorical
question because I know what you mean but the sentence implies that you
must use wishlist in some interactive mode.

Why not simply...

Note that you may want to run bin/fix_url.py to change the domain of an 
existing list.  fix_url.py must be processed by the withlist script, like so:
	bin/wishlist -l -r bin/fix_url.py <listname>

-- 
Joe Rhett
Senior Geek
Meer.net
From terri at zone12.com  Mon Oct 11 19:28:05 2004
From: terri at zone12.com (Terri Oda)
Date: Mon Oct 11 19:28:12 2004
Subject: [Mailman-Developers] referring fix_url.py
In-Reply-To: <20041011053103.GB92312@meer.net>
References: <4169D49C.8090400@is.kochi-u.ac.jp>
	<1097461472.8123.8.camel@geddy.wooz.org>
	<20041011053103.GB92312@meer.net>
Message-ID: <E9667916-1BAA-11D9-90A4-000D934FBF38@zone12.com>

On Oct 11, 2004, at 1:31 AM, Joe Rhett wrote:
> Note that you may want to run bin/fix_url.py to change the domain of an
> existing list.  fix_url.py must be processed by the withlist script, 
> like so:
> 	bin/wishlist -l -r bin/fix_url.py <listname>

This sounds more clear to me.

Also, we might want to put this somewhere in the online help for the 
list admin pages, if it's not already there.  I've had a few list 
admins get confused because there's no setting for it, just a setting 
for the email domain.  I'd suggest that we add a note along these lines 
to the help for host_name.  (eg: "Changing the domain for the web 
interface must be done from the command line by a site administrator.  
See the INSTALL file for more details on how to do this.")

From jrhett at meer.net  Mon Oct 11 19:40:17 2004
From: jrhett at meer.net (Joe Rhett)
Date: Mon Oct 11 19:41:24 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <E9667916-1BAA-11D9-90A4-000D934FBF38@zone12.com>
References: <4169D49C.8090400@is.kochi-u.ac.jp>
	<1097461472.8123.8.camel@geddy.wooz.org>
	<20041011053103.GB92312@meer.net>
	<E9667916-1BAA-11D9-90A4-000D934FBF38@zone12.com>
Message-ID: <20041011174016.GA5462@meer.net>

On Mon, Oct 11, 2004 at 01:28:05PM -0400, Terri Oda wrote:
> Also, we might want to put this somewhere in the online help for the 
> list admin pages, if it's not already there.  I've had a few list 
> admins get confused because there's no setting for it, just a setting 
> for the email domain.  I'd suggest that we add a note along these lines 
> to the help for host_name.  (eg: "Changing the domain for the web 
> interface must be done from the command line by a site administrator.  
> See the INSTALL file for more details on how to do this.")
 
On this subject, why does creating a list with the host name set the web
interface?  In no circumstance that I have ever seen are they the same,
except perhaps (in theory) for some hobbyist with a single computer?

$ newlist im@thejones.com

Sets the web interface to 'thejones.com' as well as the mail domain.  This
doesn't make a lot of sense except in the hobbyist environment.  I may be
off my rocker, but shouldn't this syntax set the mail domain and force you
to change the web URL manually?

-- 
Joe Rhett
Senior Geek
Meer.net
From msapiro at value.net  Mon Oct 11 20:47:37 2004
From: msapiro at value.net (Mark Sapiro)
Date: Mon Oct 11 20:47:50 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <20041011174016.GA5462@meer.net>
Message-ID: <PC17102004101111473702038a58cbd0@msapiro>

Joe Rhett wrote:
> 
>On this subject, why does creating a list with the host name set the web
>interface?  In no circumstance that I have ever seen are they the same,
>except perhaps (in theory) for some hobbyist with a single computer?
>
>$ newlist im@thejones.com
>
>Sets the web interface to 'thejones.com' as well as the mail domain.  This
>doesn't make a lot of sense except in the hobbyist environment.  I may be
>off my rocker, but shouldn't this syntax set the mail domain and force you
>to change the web URL manually?

Well, the help for newlist (bin/newlist --help) is pretty clear that
the notation name@domain is not the e-mail address of the list but
just a way of specifying the web domain.

<quote>
You can specify the domain to create your new list in by spelling the
listname like so:

    mylist@www.mydom.ain

where `www.mydom.ain' should be the base hostname for the URL to this
virtual hosts's lists.
</quote>

Still, I think you have a point. Mailman/Cgi/create.py checks in the
case where VIRTUAL_HOST_OVERVIEW is on to see if the hostname is in
VIRTUAL_HOSTS.

    if mm_cfg.VIRTUAL_HOST_OVERVIEW and \
           not mm_cfg.VIRTUAL_HOSTS.has_key(hostname):
        safehostname = Utils.websafe(hostname)
        request_creation(doc, cgidata,
                         _('Unknown virtual host: %(safehostname)s'))
        return

Perhaps bin/newlist should do something similar.

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

From bob at nleaudio.com  Mon Oct 11 20:52:55 2004
From: bob at nleaudio.com (Bob Puff)
Date: Mon Oct 11 20:53:00 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
References: <20041011174016.GA5462@meer.net>
	<PC17102004101111473702038a58cbd0@msapiro>
Message-ID: <20041011185247.M17709@nleaudio.com>

> <quote>
> You can specify the domain to create your new list in by spelling the
> listname like so:
> 
>     mylist@www.mydom.ain
> 
> where `www.mydom.ain' should be the base hostname for the URL to this
> virtual hosts's lists.
> </quote>
> 
> Still, I think you have a point. Mailman/Cgi/create.py checks in the
> case where VIRTUAL_HOST_OVERVIEW is on to see if the hostname is in
> VIRTUAL_HOSTS.

...Which I think is not a great idea.  On virtually all of my machines, I am
constantly adding in domains.  I certainly don't want to have yet another file
that has to be maintained just for mailman.  Let me specify the domain, or
take it from the current hostname, if you're using the web interface.

FWIW, when you use the bin/newlist command and specify the domain name, it
still doesn't generate all the virtual junk that Postfix needs.

Bob
From tkikuchi at is.kochi-u.ac.jp  Tue Oct 12 04:53:47 2004
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Tue Oct 12 04:54:06 2004
Subject: [Mailman-Developers] referring fix_url.py
In-Reply-To: <4169D49C.8090400@is.kochi-u.ac.jp>
References: <4169D49C.8090400@is.kochi-u.ac.jp>
Message-ID: <416B473B.5010406@is.kochi-u.ac.jp>

Hi,

> Since there are so many questions on 'how to fix exsiting list url',
> I want to add comments on fix_url.py in the ditribution documents.
> I am not a native english writer, so can someone fix my patch?

Thank you all for the discussions. I've just committed INSTALL and 
Defaults.py.in in the SF CVS. I keep the note in INSTALL short because 
this is not related to the first time installation and made longer in 
Defaults.py.in. I think users should consult the script itself for 
detailed usage, so both are kept rather short.

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

From jrhett at meer.net  Tue Oct 12 05:10:57 2004
From: jrhett at meer.net (Joe Rhett)
Date: Tue Oct 12 05:11:23 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <PC17102004101111473702038a58cbd0@msapiro>
References: <20041011174016.GA5462@meer.net>
	<PC17102004101111473702038a58cbd0@msapiro>
Message-ID: <20041012031057.GA14331@meer.net>

> Joe Rhett wrote:
> >On this subject, why does creating a list with the host name set the web
> >interface?  In no circumstance that I have ever seen are they the same,
	...

On Mon, Oct 11, 2004 at 11:47:37AM -0700, Mark Sapiro wrote:
> Well, the help for newlist (bin/newlist --help) is pretty clear that
> the notation name@domain is not the e-mail address of the list but
> just a way of specifying the web domain.
 
Right, but it still seems counter-intuitive to me.

1. name@domain is the format of an e-mail address, not a web address

2. How often do you change the web url for list management?

3. How often does a given list have a different identity?

3:2 is more than 100:1 in every list environment I've ever seen.  topped
with the confused syntax presented in #1, I guess I am arguing that we
change the behavior.

-- 
Joe Rhett
Senior Geek
Meer.net
From barry at python.org  Tue Oct 12 20:33:09 2004
From: barry at python.org (Barry Warsaw)
Date: Tue Oct 12 20:33:12 2004
Subject: [Mailman-Developers] referring fix_url.py
In-Reply-To: <E9667916-1BAA-11D9-90A4-000D934FBF38@zone12.com>
References: <4169D49C.8090400@is.kochi-u.ac.jp>
	<1097461472.8123.8.camel@geddy.wooz.org>
	<20041011053103.GB92312@meer.net>
	<E9667916-1BAA-11D9-90A4-000D934FBF38@zone12.com>
Message-ID: <1097605988.8581.38.camel@geddy.wooz.org>

On Mon, 2004-10-11 at 13:28, Terri Oda wrote:
> On Oct 11, 2004, at 1:31 AM, Joe Rhett wrote:
> > Note that you may want to run bin/fix_url.py to change the domain of an
> > existing list.  fix_url.py must be processed by the withlist script, 
> > like so:
> > 	bin/wishlist -l -r bin/fix_url.py <listname>
> 
> This sounds more clear to me.

Me too, thanks.

> Also, we might want to put this somewhere in the online help for the 
> list admin pages, if it's not already there.  I've had a few list 
> admins get confused because there's no setting for it, just a setting 
> for the email domain.  I'd suggest that we add a note along these lines 
> to the help for host_name.  (eg: "Changing the domain for the web 
> interface must be done from the command line by a site administrator.  
> See the INSTALL file for more details on how to do this.")

Terri, did I see correctly that you made a checkin to add something like
this to the documentation?  If so, thanks!  I'll try to push out a web
site update within a few days.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20041012/c55ea27c/attachment.pgp
From dallas at dreamhost.com  Wed Oct 13 00:58:32 2004
From: dallas at dreamhost.com (Dallas Bethune)
Date: Wed Oct 13 00:58:36 2004
Subject: [Mailman-Developers] incorrect MIME?
Message-ID: <3D53BDE4-1CA2-11D9-A395-000A95AA76E0@dreamhost.com>

I'm getting a report of some Mailman messages seemingly not having 
correct MIME encoding and the footer and sometimes the message itself 
appears as an attachment to the user.  The originating messages may be 
coming primarily from AOL users.  Has anyone else heard of this 
problem?

	Dallas

From msapiro at value.net  Wed Oct 13 02:54:51 2004
From: msapiro at value.net (Mark Sapiro)
Date: Wed Oct 13 02:55:12 2004
Subject: [Mailman-Developers] incorrect MIME?
In-Reply-To: <3D53BDE4-1CA2-11D9-A395-000A95AA76E0@dreamhost.com>
Message-ID: <PC17102004101217545107341b65ee31@msapiro>

Dallas Bethune wrote:

>I'm getting a report of some Mailman messages seemingly not having 
>correct MIME encoding and the footer and sometimes the message itself 
>appears as an attachment to the user.  The originating messages may be 
>coming primarily from AOL users.  Has anyone else heard of this 
>problem?

See http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.039.htp

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

From tkikuchi at is.kochi-u.ac.jp  Sat Oct 16 07:52:01 2004
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Sat Oct 16 07:52:15 2004
Subject: [Mailman-Developers] Can we remove nimda.txt ?
Message-ID: <4170B701.7060103@is.kochi-u.ac.jp>

Hi Developers,

I have committed a few new feature in the Release_2_1-maint branch
of mailman CVS. Please export/checkout the new source code and test
them in your test/working mailman installation and feed back.

Also, I want to ask 'nimda.txt' in the tests/msgs directory is of
any use in the mailman source code. None of the test scripts refer
to this file. I even did "find . | xargs grep nimda" only to get
"Binary file ./tests/msgs matches". If none of you can find usage
of this file, I want to remove from the source tree because some
companies prohibit to download a file which contain nimda file.
(I know it's nonsense but ...)

Here is the diff for current NEWS file. (I believe Barry can
fix my poor English.) More will come later because I get requests
of merging patches personally. But, please be patient as I will
check the patches and bugs for assigning to myself when it comes
your turn. ;-)

Cheers,
-- 
Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp

Update of /cvsroot/mailman/mailman
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv8029

Modified Files:
      Tag: Release_2_1-maint
	NEWS
Log Message:
update NEWS for new features and bug fixes


Index: NEWS
===================================================================
RCS file: /cvsroot/mailman/mailman/NEWS,v
retrieving revision 2.43.2.28
retrieving revision 2.43.2.29
diff -u -d -r2.43.2.28 -r2.43.2.29
--- NEWS	18 May 2004 02:15:55 -0000	2.43.2.28
+++ NEWS	16 Oct 2004 04:54:33 -0000	2.43.2.29
@@ -6,7 +6,32 @@

 2.1.6 (XX-XXX-200X)

-    - Bugs and patches: 955381 (older Python compatibility).
+    - List owners can now set how many days to hold the messages in
moderator
+      request queue. cron/checkdb automatically discard old messages.
(790494)
+
+    - Improved mail address sanity check. (1030228)
+
+    - SpamDetect.py now checks attatchment header. (1026977)
+
+    - Subject_prefix can be configured to include sequential number which
+      is taken from post_id variable. Also, the prefix is always put at
+      the start of the subject, i.e. like "[list-name] Re: original
subject"
+
+    - Now, list owners can use Scrubber to get the attachments scrubbed
+      (held in the web archive), if the site admin permits it in
mm_cfg.py.
+      Also, introduced are SCRUBBER_DONT_USE_ATTACHMENT_FILENAME and
+      SCRUBBER_USE_ATTACHMENT_FILENAME_EXTENSION in Defaults.py for
scrubber
+      behavior. (904850)
+
+    - Filter attachments by filename extensions. (1027882)
+
+    - Bugs and patches: 955381 (older Python compatibility),
1020102/1013079/
+      1020013 (fix spam filter removed), 665569 (newer postfix bounce
+      detection), 970383 (moderator -1 admin requests pending), 873035
+      (subject handling in -request mail), 799166/946554 (makefile
+      compatibility), 872068 (add header/footer via unicode), 1032434
+      (KNOWN_SPAMMERS check for multi-header), 1025372 (empty Cc:),
+      789015 (fix pipermail URL),

 2.1.5 (15-May-2004)


From brad at stop.mail-abuse.org  Sat Oct 16 08:22:16 2004
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Sat Oct 16 08:22:19 2004
Subject: [Mailman-Developers] Can we remove nimda.txt ?
In-Reply-To: <4170B701.7060103@is.kochi-u.ac.jp>
References: <4170B701.7060103@is.kochi-u.ac.jp>
Message-ID: <p0600200bbd966d04ed83@[24.165.137.33]>

At 2:52 PM +0900 2004-10-16, Tokio Kikuchi wrote:

>  Here is the diff for current NEWS file. (I believe Barry can
>  fix my poor English.) More will come later because I get requests
>  of merging patches personally. But, please be patient as I will
>  check the patches and bugs for assigning to myself when it comes
>  your turn. ;-)

	While we're at it, can we update the documentation so that we can 
deprecate FAQ entries 5.8 and 5.12?  It sure would be nice to not 
have so many people asking about support questions with Mailman 2.1.5 
using older versions of Python, or MTAs that don't implement VERP.

	Also, if we're going to require VERP support on the MTA with 
2.1.5 and beyond, can we go ahead and turn on "VERP_CONFIRMATIONS = 
Yes" in mm_cfg.py, so that we can also eliminate all the questions 
regarding the funky subject lines which led to FAQ 4.52?


	On a separate matter, the way that full personalization works is 
really, really annoying.  When enabling this on lists I manage, I've 
gotten more complaints than on all other items combined on those same 
lists.

	I'm going to work out a way to hack out the most offensive things 
and submit a patch, but has anyone else had issues with it?  Am I 
totally out in left field, or does someone else already have a patch 
that I haven't seen?

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

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

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

   SAGE member since 1995.  See <http://www.sage.org/> for more info.
From fil at rezo.net  Sat Oct 16 10:30:10 2004
From: fil at rezo.net (Fil)
Date: Sat Oct 16 10:30:07 2004
Subject: [Mailman-Developers] this mail-gid problem
Message-ID: <20041016083009.GI21335@rezo.net>

Hi,

there is something really nasty about the way postfix chooses its UID/GID
(recall: it's based on the UID of the alias file where the alias has been
taken from).

So if you have a somewhat complex configuration, you can have postfix invoke
the mailman command from two different aliases files (/etc/aliases and
/var/local/mailman/data/aliases), which don't necessarily have the same UID.

And then you're toast by Mailman gid check.

I would like to know if this check can be expanded to list all GID that
mailman will accept? Or if I should just be more carful in setting up my
system? :)

The question is really a FAQ, but the answer is not fully satisfying.

README.POSTFIX says:

    - When you configure Mailman, use the --with-mail-gid=mailman
      switch (actually, this will be the default if you configured
      Mailman after adding the `mailman' owner).  Because the owner of
      the aliases.db file is `mailman', Postfix will execute Mailman's
      wrapper program as uid and gid mailman.

I'd like to have either the possibility of configuring:
        --with-mail-gid=mailman,nogroup

or an update in the README.POSTFIX file saying, more explicitly, that all
mailman calls from postfix should be done through aliases files that all
belong to the same user (mailman) that has the mailman GID... but I'm not
sure of the wording that should be used - so weird is this.

-- Fil

From fil at rezo.net  Sat Oct 16 11:27:36 2004
From: fil at rezo.net (Fil)
Date: Sat Oct 16 11:27:37 2004
Subject: [Mailman-Developers] get_sender ?
Message-ID: <20041016092736.GO21335@rezo.net>

I've just upgraded my system to CVS, and I get this:

Oct 16 11:26:36 2004 (19525) Uncaught runner exception: 'str' object has no
attribute 'get_sender'
Oct 16 11:26:36 2004 (19525) Traceback (most recent call last):
  File "/var/local/mailman/Mailman/Queue/Runner.py", line 111, in _oneloop
    self._onefile(msg, msgdata)
  File "/var/local/mailman/Mailman/Queue/Runner.py", line 159, in _onefile
    sender = msg.get_sender()
AttributeError: 'str' object has no attribute 'get_sender'



-- Fil

From fil at rezo.net  Sat Oct 16 11:44:31 2004
From: fil at rezo.net (Fil)
Date: Sat Oct 16 11:44:32 2004
Subject: [Mailman-Developers] get_sender ? + .get ?
In-Reply-To: <20041016092736.GO21335@rezo.net>
References: <20041016092736.GO21335@rezo.net>
Message-ID: <20041016094430.GQ21335@rezo.net>

> I've just upgraded my system to CVS, and I get this:
> 
> Oct 16 11:26:36 2004 (19525) Uncaught runner exception: 'str' object has no
> attribute 'get_sender'
> Oct 16 11:26:36 2004 (19525) Traceback (most recent call last):
>   File "/var/local/mailman/Mailman/Queue/Runner.py", line 111, in _oneloop
>     self._onefile(msg, msgdata)
>   File "/var/local/mailman/Mailman/Queue/Runner.py", line 159, in _onefile
>     sender = msg.get_sender()
> AttributeError: 'str' object has no attribute 'get_sender'


I have corrected this by removeing the offending line (which selects the
user language)... and now Mailman is processing old bounce files and I get
lots of the following:

    keepqueued = self._dispose(mlist, msg, msgdata)
  File "/var/local/mailman/Mailman/Queue/BounceRunner.py", line 182, in
_dispose
    if msg.get('to', '') == Utils.get_site_email(extra='owner'):
AttributeError: 'str' object has no attribute 'get'

-- Fil

From tkikuchi at is.kochi-u.ac.jp  Sat Oct 16 13:37:16 2004
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Sat Oct 16 13:37:30 2004
Subject: [Mailman-Developers] get_sender ? + .get ?
In-Reply-To: <20041016094430.GQ21335@rezo.net>
References: <20041016092736.GO21335@rezo.net> <20041016094430.GQ21335@rezo.net>
Message-ID: <417107EC.1070609@is.kochi-u.ac.jp>

Are you sure you checked out Release_2_1-maint ? Command should be
% cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/mailman\
   co -r  Release_2_1-maint mailman

Fil wrote:

>>I've just upgraded my system to CVS, and I get this:
>>
>>Oct 16 11:26:36 2004 (19525) Uncaught runner exception: 'str' object has no
>>attribute 'get_sender'
>>Oct 16 11:26:36 2004 (19525) Traceback (most recent call last):
>>  File "/var/local/mailman/Mailman/Queue/Runner.py", line 111, in _oneloop
>>    self._onefile(msg, msgdata)
>>  File "/var/local/mailman/Mailman/Queue/Runner.py", line 159, in _onefile
>>    sender = msg.get_sender()
>>AttributeError: 'str' object has no attribute 'get_sender'
> 
> 
> 
> I have corrected this by removeing the offending line (which selects the
> user language)... and now Mailman is processing old bounce files and I get
> lots of the following:
> 
>     keepqueued = self._dispose(mlist, msg, msgdata)
>   File "/var/local/mailman/Mailman/Queue/BounceRunner.py", line 182, in
> _dispose
>     if msg.get('to', '') == Utils.get_site_email(extra='owner'):
> AttributeError: 'str' object has no attribute 'get'
> 
> -- Fil
> 

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

From fil at rezo.net  Sat Oct 16 15:07:26 2004
From: fil at rezo.net (Fil)
Date: Sat Oct 16 15:07:27 2004
Subject: [Mailman-Developers] small scubber issue
Message-ID: <20041016130726.GA29607@rezo.net>

I've just tried the scrubber, and Apple's Mail does a bad job parsing the
message's scrubbed URL (that is followed with the signature), so the hits
went to

Oct 16 15:02:44 2004 (29099) Private archive file not found:
/var/local/mailman/archives/private/listes/attachments/20041016/3557b8e1/villaasen.jpg_______________________________________________

The underscores are the signature's first line

-- Fil

From jwblist at olympus.net  Sat Oct 16 17:52:15 2004
From: jwblist at olympus.net (John W. Baxter)
Date: Sat Oct 16 17:52:29 2004
Subject: [Mailman-Developers] Can we remove nimda.txt ?
In-Reply-To: <4170B701.7060103@is.kochi-u.ac.jp>
Message-ID: <BD9691BF.1755B%jwblist@olympus.net>

On 10/15/2004 22:52, "Tokio Kikuchi" <tkikuchi@is.kochi-u.ac.jp> wrote:

> Also, I want to ask 'nimda.txt' in the tests/msgs directory is of
> any use in the mailman source code. None of the test scripts refer
> to this file. I even did "find . | xargs grep nimda" only to get
> "Binary file ./tests/msgs matches". If none of you can find usage
> of this file, I want to remove from the source tree because some
> companies prohibit to download a file which contain nimda file.
> (I know it's nonsense but ...)

My guess is that the nimda.txt file is left over and can be removed without
harm.

You might want to refer folks who want to run test "virus" messages through
their Mailman system ("system" = the MTA and its filtering and Mailman and
whatever else is involved at a given site) to
   http://www.eicar.org
(note...eicar.com is very different).

By including the reference, you avoid having anything in the distribution
which triggers (sensible) virus scanners.

  --John (who just used eicar yesterday in another context)

From fred at bytesforall.org  Sat Oct 16 21:48:16 2004
From: fred at bytesforall.org (Frederick Noronha (FN))
Date: Sat Oct 16 22:59:03 2004
Subject: [Mailman-Developers] Changing the name of a list already set-up
Message-ID: <Pine.LNX.4.60.0410170117490.2239@news.goa.bytesforall.org>

Is there an easy way of changing the name of a Mailman list already set 
up? Thanks, FN
----------------------------------------------------------------------------
Frederick Noronha (FN)                    Nr Convent Saligao 403511 GoaIndia
Freelance Journalist                      P: 832-2409490 M: 9822122436
http://www.livejournal.com/users/goalinks http://fn.swiki.net
http://www.ryze.com/go/fredericknoronha   http://fn-floss.notlong.com
----------------------------------------------------------------------------
Difficulties to send email across? Write to fredericknoronha at vsnl.net
============================================================================
From relson at osagesoftware.com  Sat Oct 16 23:13:35 2004
From: relson at osagesoftware.com (David Relson)
Date: Sat Oct 16 23:13:39 2004
Subject: [Mailman-Developers] Can we remove nimda.txt ?
In-Reply-To: <BD9691BF.1755B%jwblist@olympus.net>
References: <4170B701.7060103@is.kochi-u.ac.jp>
	<BD9691BF.1755B%jwblist@olympus.net>
Message-ID: <20041016171335.27719baf@osage.osagesoftware.com>

On Sat, 16 Oct 2004 08:52:15 -0700
John W. Baxter wrote:

...[snip]...

> You might want to refer folks who want to run test "virus" messages
> through their Mailman system ("system" = the MTA and its filtering and
> Mailman and whatever else is involved at a given site) to
>    http://www.eicar.org
> (note...eicar.com is very different).

They are??? www.eicar.org and www.eicar.com look identical (and have the
same IP address).

> 
> By including the reference, you avoid having anything in the
> distribution which triggers (sensible) virus scanners.
> 
>   --John (who just used eicar yesterday in another context)
From tkikuchi at is.kochi-u.ac.jp  Sun Oct 17 02:53:27 2004
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Sun Oct 17 02:53:42 2004
Subject: [Mailman-Developers] small scubber issue
In-Reply-To: <20041016130726.GA29607@rezo.net>
References: <20041016130726.GA29607@rezo.net>
Message-ID: <4171C287.3010701@is.kochi-u.ac.jp>

Hi Fil,

Thank you for testing.

Fil wrote:

> I've just tried the scrubber, and Apple's Mail does a bad job parsing the
> message's scrubbed URL (that is followed with the signature), so the hits
> went to
> 
> Oct 16 15:02:44 2004 (29099) Private archive file not found:
> /var/local/mailman/archives/private/listes/attachments/20041016/3557b8e1/villaasen.jpg_______________________________________________
> 
> The underscores are the signature's first line

Assuming the signature is of list footer, I've done every effort to
separate lines with '\n'. See Scrubber.py and Decorate.py. How about
reading the mail by other MUAs. If it is same, would you send me the
original test message and the one distributed by mailman.

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

From tkikuchi at is.kochi-u.ac.jp  Sun Oct 17 03:29:08 2004
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Sun Oct 17 03:29:22 2004
Subject: [Mailman-Developers] Can we remove nimda.txt ?
In-Reply-To: <p0600200bbd966d04ed83@[24.165.137.33]>
References: <4170B701.7060103@is.kochi-u.ac.jp>
	<p0600200bbd966d04ed83@[24.165.137.33]>
Message-ID: <4171CAE4.7030404@is.kochi-u.ac.jp>

Hi,

Brad Knowles wrote:

> At 2:52 PM +0900 2004-10-16, Tokio Kikuchi wrote:
> 
>>  Here is the diff for current NEWS file. (I believe Barry can
>>  fix my poor English.) More will come later because I get requests
>>  of merging patches personally. But, please be patient as I will
>>  check the patches and bugs for assigning to myself when it comes
>>  your turn. ;-)
> 
> 
>     While we're at it, can we update the documentation so that we can 
> deprecate FAQ entries 5.8 and 5.12?  It sure would be nice to not have 
> so many people asking about support questions with Mailman 2.1.5 using 
> older versions of Python, or MTAs that don't implement VERP.

Can you write a patch for INSTALL/README and upload it to SF patch
tracker? It would be highly appreciated.
I myself updated one of my server's sendmail to use 2.1.5.

>     Also, if we're going to require VERP support on the MTA with 2.1.5 
> and beyond, can we go ahead and turn on "VERP_CONFIRMATIONS = Yes" in 
> mm_cfg.py, so that we can also eliminate all the questions regarding the 
> funky subject lines which led to FAQ 4.52?

Sounds reasonable. Anyone against this?

>     On a separate matter, the way that full personalization works is 
> really, really annoying.  When enabling this on lists I manage, I've 
> gotten more complaints than on all other items combined on those same 
> lists.
> 
>     I'm going to work out a way to hack out the most offensive things 
> and submit a patch, but has anyone else had issues with it?  Am I 
> totally out in left field, or does someone else already have a patch 
> that I haven't seen?
> 

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

From tkikuchi at is.kochi-u.ac.jp  Sun Oct 17 03:51:32 2004
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Sun Oct 17 03:51:45 2004
Subject: [Mailman-Developers] Can we remove nimda.txt ?
In-Reply-To: <4171CAE4.7030404@is.kochi-u.ac.jp>
References: <4170B701.7060103@is.kochi-u.ac.jp>	<p0600200bbd966d04ed83@[24.165.137.33]>
	<4171CAE4.7030404@is.kochi-u.ac.jp>
Message-ID: <4171D024.9060304@is.kochi-u.ac.jp>


>>     Also, if we're going to require VERP support on the MTA with 2.1.5 
>> and beyond, can we go ahead and turn on "VERP_CONFIRMATIONS = Yes" in 
>> mm_cfg.py, so that we can also eliminate all the questions regarding 
>> the funky subject lines which led to FAQ 4.52?
> 
> 
> Sounds reasonable. Anyone against this?

Oops. This is only for "invite". Looks like patch is there, so I should
commit into the CVS.

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

From brad at stop.mail-abuse.org  Sun Oct 17 04:22:24 2004
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Sun Oct 17 04:22:21 2004
Subject: [Mailman-Developers] Can we remove nimda.txt ?
In-Reply-To: <4171CAE4.7030404@is.kochi-u.ac.jp>
References: <4170B701.7060103@is.kochi-u.ac.jp>
	<p0600200bbd966d04ed83@[24.165.137.33]>
	<4171CAE4.7030404@is.kochi-u.ac.jp>
Message-ID: <p06002007bd9787b19695@[192.168.1.100]>

At 10:29 AM +0900 2004-10-17, Tokio Kikuchi wrote:

>>      While we're at it, can we update the documentation so that we can
>>  deprecate FAQ entries 5.8 and 5.12?  It sure would be nice to not have
>>  so many people asking about support questions with Mailman 2.1.5 using
>>  older versions of Python, or MTAs that don't implement VERP.
>
>  Can you write a patch for INSTALL/README and upload it to SF patch
>  tracker? It would be highly appreciated.

	I'll try to do this within the next few days, if someone else 
doesn't beat me to it.

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

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

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

   SAGE member since 1995.  See <http://www.sage.org/> for more info.
From gustavorfranco at gmail.com  Sun Oct 17 05:48:10 2004
From: gustavorfranco at gmail.com (Gustavo Franco)
Date: Sun Oct 17 05:48:13 2004
Subject: [Mailman-Developers] Can we remove nimda.txt ?
In-Reply-To: <4170B701.7060103@is.kochi-u.ac.jp>
References: <4170B701.7060103@is.kochi-u.ac.jp>
Message-ID: <5fabd6fd041016204825cb3a36@mail.gmail.com>

Hi,

Anyone cares about 1029275 (Maximum number of members per list) ? This
patch was submitted at sf and here a month ago and still nothing. I
just want to read "we don't want this feature" or "it's a bad patch,
it's needs more work here and there". Kikuchi ?

Thank you for keep contributors motivated.

Best regards,
Gustavo Franco
From terri at zone12.com  Mon Oct 18 00:53:12 2004
From: terri at zone12.com (Terri Oda)
Date: Mon Oct 18 00:53:17 2004
Subject: [Mailman-Developers] referring fix_url.py
In-Reply-To: <1097605988.8581.38.camel@geddy.wooz.org>
References: <4169D49C.8090400@is.kochi-u.ac.jp>
	<1097461472.8123.8.camel@geddy.wooz.org>
	<20041011053103.GB92312@meer.net>
	<E9667916-1BAA-11D9-90A4-000D934FBF38@zone12.com>
	<1097605988.8581.38.camel@geddy.wooz.org>
Message-ID: <52BCFC1F-208F-11D9-AE96-000D934FBF38@zone12.com>


On Oct 12, 2004, at 2:33 PM, Barry Warsaw wrote:
> On Mon, 2004-10-11 at 13:28, Terri Oda wrote:
>> Also, we might want to put this somewhere in the online help for the
>> list admin pages, if it's not already there.  I've had a few list
>> admins get confused because there's no setting for it, just a setting
>> for the email domain.  I'd suggest that we add a note along these 
>> lines
>> to the help for host_name.  (eg: "Changing the domain for the web
>> interface must be done from the command line by a site administrator.
>> See the INSTALL file for more details on how to do this.")
>
> Terri, did I see correctly that you made a checkin to add something 
> like
> this to the documentation?  If so, thanks!  I'll try to push out a web
> site update within a few days.

I think it's in the documentation, but not in the online help, so 
people'd have to know to go read the site admin documentation.  I'll 
see about putting it in the actual online help, but pushing the 
documentation updates through to the site is a good idea anyhow. :)

If anyone's interested looking through the still incomplete site admin 
docs before Barry puts 'em up, they're available in CVS and can be 
built to a variety of document formats using the "mkhowto" tool that 
comes with python's documentation stuff.

  Terri

From terri at zone12.com  Mon Oct 18 01:02:44 2004
From: terri at zone12.com (Terri Oda)
Date: Mon Oct 18 01:02:45 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <20041012031057.GA14331@meer.net>
References: <20041011174016.GA5462@meer.net>
	<PC17102004101111473702038a58cbd0@msapiro>
	<20041012031057.GA14331@meer.net>
Message-ID: <A7F8452C-2090-11D9-AE96-000D934FBF38@zone12.com>


On Oct 11, 2004, at 11:10 PM, Joe Rhett wrote:
> On Mon, Oct 11, 2004 at 11:47:37AM -0700, Mark Sapiro wrote:
>> Well, the help for newlist (bin/newlist --help) is pretty clear that
>> the notation name@domain is not the e-mail address of the list but
>> just a way of specifying the web domain.
>
> Right, but it still seems counter-intuitive to me.

I'm with Joe on this one -- just because it's a documented oddity 
doesn't make it the right way to do things.

Is there any particular reason we couldn't change the newlist script to 
accept "name domain" instead of "name@domain" ?  It's just that much 
less confusing if we don't have this thing that looks like an email 
address but isn't.  I can't believe anyone's that attached to the 
confusing syntax, and the increased usability seems worth the small 
patch this'll take.

  Terri

From terri at zone12.com  Mon Oct 18 01:11:22 2004
From: terri at zone12.com (Terri Oda)
Date: Mon Oct 18 01:11:24 2004
Subject: [Mailman-Developers] Can we remove nimda.txt ?
In-Reply-To: <4170B701.7060103@is.kochi-u.ac.jp>
References: <4170B701.7060103@is.kochi-u.ac.jp>
Message-ID: <DC9D85B2-2091-11D9-AE96-000D934FBF38@zone12.com>

On Oct 16, 2004, at 1:52 AM, Tokio Kikuchi wrote:
> Here is the diff for current NEWS file. (I believe Barry can
> fix my poor English.) More will come later because I get requests
> of merging patches personally. But, please be patient as I will
> check the patches and bugs for assigning to myself when it comes
> your turn. ;-)

Well, I'm not Barry, but I'll checked your English and it looks good to 
me, in case you want another opinion.

> +    - Bugs and patches: 955381 (older Python compatibility),
> 1020102/1013079/
> +      1020013 (fix spam filter removed), 665569 (newer postfix bounce
> +      detection), 970383 (moderator -1 admin requests pending), 873035
> +      (subject handling in -request mail), 799166/946554 (makefile
> +      compatibility), 872068 (add header/footer via unicode), 1032434
> +      (KNOWN_SPAMMERS check for multi-header), 1025372 (empty Cc:),
> +      789015 (fix pipermail URL),

If Barry pushes through the documentation updates I made, we'll also 
have fixed 948152 (Out of date link on Docs webpage) but I don't know 
if this should go in the NEWS file or no since it's not exactly a bug 
related to the release.  We should remember to mark this bug as fixed, 
though, whenever the update happens.

  Terri

From terri at zone12.com  Mon Oct 18 01:13:42 2004
From: terri at zone12.com (Terri Oda)
Date: Mon Oct 18 01:13:45 2004
Subject: [Mailman-Developers] referring fix_url.py
In-Reply-To: <52BCFC1F-208F-11D9-AE96-000D934FBF38@zone12.com>
References: <4169D49C.8090400@is.kochi-u.ac.jp>
	<1097461472.8123.8.camel@geddy.wooz.org>
	<20041011053103.GB92312@meer.net>
	<E9667916-1BAA-11D9-90A4-000D934FBF38@zone12.com>
	<1097605988.8581.38.camel@geddy.wooz.org>
	<52BCFC1F-208F-11D9-AE96-000D934FBF38@zone12.com>
Message-ID: <2FF0B61E-2092-11D9-AE96-000D934FBF38@zone12.com>

On Oct 17, 2004, at 6:53 PM, Terri Oda wrote:
> If anyone's interested looking through the still incomplete site admin 
> docs before Barry puts 'em up, they're available in CVS and can be 
> built to a variety of document formats using the "mkhowto" tool that 
> comes with python's documentation stuff.

I should mention that I've already put these online in various formats 
so people wouldn't have to do build them themselves:

http://terri.zone12.com/doc/mailman/

From bob at nleaudio.com  Mon Oct 18 02:43:48 2004
From: bob at nleaudio.com (Bob Puff)
Date: Mon Oct 18 02:43:52 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <A7F8452C-2090-11D9-AE96-000D934FBF38@zone12.com>
References: <20041011174016.GA5462@meer.net>
	<PC17102004101111473702038a58cbd0@msapiro>
	<20041012031057.GA14331@meer.net>
	<A7F8452C-2090-11D9-AE96-000D934FBF38@zone12.com>
Message-ID: <20041018004118.M81461@nleaudio.com>

Hmm I guess I still don't get why "name@domain" is confusing, because that
-is- the posting address of the list!  If you want to add another field for
domain, that's fine; but I think the current behaviour makes sense.

Also, as I stated before, the web-based create should take the hostname used
as the domain name.  It currently forces one domain.

Bob


---------- Original Message -----------
From: Terri Oda <terri@zone12.com>
To: Joe Rhett <jrhett@meer.net>
Cc: mailman-developers@python.org
Sent: Sun, 17 Oct 2004 19:02:44 -0400
Subject: Re: [Mailman-Developers] on the subject of fix_url, list creation
with @ is non-intuitive..

> On Oct 11, 2004, at 11:10 PM, Joe Rhett wrote:
> > On Mon, Oct 11, 2004 at 11:47:37AM -0700, Mark Sapiro wrote:
> >> Well, the help for newlist (bin/newlist --help) is pretty clear that
> >> the notation name@domain is not the e-mail address of the list but
> >> just a way of specifying the web domain.
> >
> > Right, but it still seems counter-intuitive to me.
> 
> I'm with Joe on this one -- just because it's a documented oddity 
> doesn't make it the right way to do things.
> 
> Is there any particular reason we couldn't change the newlist script 
> to accept "name domain" instead of "name@domain" ?  It's just that 
> much less confusing if we don't have this thing that looks like an 
> email address but isn't.  I can't believe anyone's that attached to 
> the confusing syntax, and the increased usability seems worth the 
> small patch this'll take.
> 
>   Terri
> 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com
------- End of Original Message -------

From barry at python.org  Mon Oct 18 02:56:30 2004
From: barry at python.org (Barry Warsaw)
Date: Mon Oct 18 02:56:37 2004
Subject: [Mailman-Developers] Can we remove nimda.txt ?
In-Reply-To: <4170B701.7060103@is.kochi-u.ac.jp>
References: <4170B701.7060103@is.kochi-u.ac.jp>
Message-ID: <1098060990.18270.16.camel@geddy.wooz.org>

On Sat, 2004-10-16 at 01:52, Tokio Kikuchi wrote:

> I have committed a few new feature in the Release_2_1-maint branch
> of mailman CVS. Please export/checkout the new source code and test
> them in your test/working mailman installation and feed back.

Awesome, and thanks!

> Also, I want to ask 'nimda.txt' in the tests/msgs directory is of
> any use in the mailman source code. None of the test scripts refer
> to this file. I even did "find . | xargs grep nimda" only to get
> "Binary file ./tests/msgs matches". If none of you can find usage
> of this file, I want to remove from the source tree because some
> companies prohibit to download a file which contain nimda file.
> (I know it's nonsense but ...)

Yes, you can get rid of it.  It was there once to test the email parser,
but it's no longer necessary.

> Here is the diff for current NEWS file. (I believe Barry can
> fix my poor English.) More will come later because I get requests
> of merging patches personally. But, please be patient as I will
> check the patches and bugs for assigning to myself when it comes
> your turn. ;-)

Thanks -- I've made some minor corrections to the file.  I appreciate
all your help in working on 2.1.6.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20041017/1b698533/attachment.pgp
From barry at python.org  Mon Oct 18 03:07:30 2004
From: barry at python.org (Barry Warsaw)
Date: Mon Oct 18 03:07:33 2004
Subject: [Mailman-Developers] Can we remove nimda.txt ?
In-Reply-To: <p0600200bbd966d04ed83@[24.165.137.33]>
References: <4170B701.7060103@is.kochi-u.ac.jp>
	<p0600200bbd966d04ed83@[24.165.137.33]>
Message-ID: <1098061650.18272.26.camel@geddy.wooz.org>

On Sat, 2004-10-16 at 02:22, Brad Knowles wrote:

> 	While we're at it, can we update the documentation so that we can 
> deprecate FAQ entries 5.8 and 5.12?  It sure would be nice to not 
> have so many people asking about support questions with Mailman 2.1.5 
> using older versions of Python, or MTAs that don't implement VERP.

As to 5.8 and 4.42, I do consider the fact that Mailman 2.1.5 breaks
under older Python's a bug that should be fixed in 2.1.6 (and was fixed
in CVS very early on).  Mailman 2.1.x should still run under Python
2.1.  I do however /recommend/ using Python 2.3.

As for 5.12, I think it's an oversight on my part that the bounce probe
feature requires VERP support in the MTA.  I would like to see the probe
become optional in 2.1.6 so that if you do not have VERP, Mailman will
process bounces in the 2.1.4 way (i.e. not send a probe).  I don't know
if that's feasible or even desirable -- how much pain is it for
mailman-users that VERP is required?  From 5.12, it sounds like those
using Mailman in some hosting arrangements are prevented from upgrading
because of this.  That's unfortunate.

> 	Also, if we're going to require VERP support on the MTA with 
> 2.1.5 and beyond, can we go ahead and turn on "VERP_CONFIRMATIONS = 
> Yes" in mm_cfg.py, so that we can also eliminate all the questions 
> regarding the funky subject lines which led to FAQ 4.52?

/Should/ we require VERP?  My preference would be "no".

> 	On a separate matter, the way that full personalization works is 
> really, really annoying.  When enabling this on lists I manage, I've 
> gotten more complaints than on all other items combined on those same 
> lists.

Can you provide more detail about those complaints?  What don't people
like about it?  The only difference between "personalized" messages and
"fully personalized" messages is the To header, so if they don't like
that, you shouldn't fully personalize the messages.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20041017/d8bd7008/attachment.pgp
From barry at python.org  Mon Oct 18 03:08:24 2004
From: barry at python.org (Barry Warsaw)
Date: Mon Oct 18 03:08:25 2004
Subject: [Mailman-Developers] Can we remove nimda.txt ?
In-Reply-To: <p0600200bbd966d04ed83@[24.165.137.33]>
References: <4170B701.7060103@is.kochi-u.ac.jp>
	<p0600200bbd966d04ed83@[24.165.137.33]>
Message-ID: <1098061704.18273.28.camel@geddy.wooz.org>

On Sat, 2004-10-16 at 02:22, Brad Knowles wrote:

> 	While we're at it, can we update the documentation so that we can 
> deprecate FAQ entries 5.8 and 5.12?  It sure would be nice to not 
> have so many people asking about support questions with Mailman 2.1.5 
> using older versions of Python, or MTAs that don't implement VERP.

Oh, BTW, could you (or someone) update those FAQ entries to explain my
intent about Python backward compatibility?  Thanks,

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20041017/9a6239f6/attachment.pgp
From barry at python.org  Mon Oct 18 03:12:54 2004
From: barry at python.org (Barry Warsaw)
Date: Mon Oct 18 03:12:56 2004
Subject: [Mailman-Developers] Can we remove nimda.txt ?
In-Reply-To: <5fabd6fd041016204825cb3a36@mail.gmail.com>
References: <4170B701.7060103@is.kochi-u.ac.jp>
	<5fabd6fd041016204825cb3a36@mail.gmail.com>
Message-ID: <1098061974.18277.32.camel@geddy.wooz.org>

On Sat, 2004-10-16 at 23:48, Gustavo Franco wrote:

> Anyone cares about 1029275 (Maximum number of members per list) ? This
> patch was submitted at sf and here a month ago and still nothing. I
> just want to read "we don't want this feature" or "it's a bad patch,
> it's needs more work here and there". Kikuchi ?

I'm not personally in favor of adding this feature to the 2.1 line.  I
understand that because 2.2 will never come out and I'm way behind on
3.0 that pressure builds to add new features to the 2.1 point releases. 
I'd still like to resist that pressure as much as possible, but I can
support getting some new features (in a backward compatible way) into
2.1.(x>5).  Let's take them on a case-by-case basis (and Tokio has a lot
of sway here because he's doing the hard work ;).

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20041017/1a581208/attachment-0001.pgp
From terri at zone12.com  Mon Oct 18 08:32:21 2004
From: terri at zone12.com (Terri Oda)
Date: Mon Oct 18 08:32:32 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <20041018004118.M81461@nleaudio.com>
References: <20041011174016.GA5462@meer.net>
	<PC17102004101111473702038a58cbd0@msapiro>
	<20041012031057.GA14331@meer.net>
	<A7F8452C-2090-11D9-AE96-000D934FBF38@zone12.com>
	<20041018004118.M81461@nleaudio.com>
Message-ID: <773259D9-20CF-11D9-AF51-000D934FBF38@zone12.com>

On Oct 17, 2004, at 8:43 PM, Bob Puff wrote:
> Hmm I guess I still don't get why "name@domain" is confusing, because 
> that
> -is- the posting address of the list!  If you want to add another 
> field for
> domain, that's fine; but I think the current behaviour makes sense.

Is it always the posting address, though?  If you create a list:

mylist@www.example.com

isn't it possible that www.example.com is just a webserver and the mail 
is actually handled by some other domain (eg: lists.example.com) which 
may not be the same machine?

From iane at sussex.ac.uk  Mon Oct 18 11:41:46 2004
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Mon Oct 18 11:41:49 2004
Subject: [Mailman-Developers] small scubber issue
In-Reply-To: <4171C287.3010701@is.kochi-u.ac.jp>
References: <20041016130726.GA29607@rezo.net>
	<4171C287.3010701@is.kochi-u.ac.jp>
Message-ID: <C23E51EF1A400A39C69AF668@lewes.staff.uscs.susx.ac.uk>



--On Sunday, October 17, 2004 9:53 am +0900 Tokio Kikuchi 
<tkikuchi@is.kochi-u.ac.jp> wrote:

> Hi Fil,
>
> Thank you for testing.
>
> Fil wrote:
>
>> I've just tried the scrubber, and Apple's Mail does a bad job parsing the
>> message's scrubbed URL (that is followed with the signature), so the hits
>> went to
>>
>> Oct 16 15:02:44 2004 (29099) Private archive file not found:
>> /var/local/mailman/archives/private/listes/attachments/20041016/3557b8e1
>> /villaasen.jpg_______________________________________________
>>
>> The underscores are the signature's first line
>
> Assuming the signature is of list footer, I've done every effort to
> separate lines with '\n'. See Scrubber.py and Decorate.py. How about
> reading the mail by other MUAs. If it is same, would you send me the
> original test message and the one distributed by mailman.

Does the scrubber wrap the URLs in angle brackets, per the appendix to rfc 
1738?

-- 
Ian Eiloart
Servers Team
Sussex University ITS

From brad at stop.mail-abuse.org  Mon Oct 18 12:16:17 2004
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Mon Oct 18 12:24:06 2004
Subject: [Mailman-Developers] Can we remove nimda.txt ?
In-Reply-To: <1098061704.18273.28.camel@geddy.wooz.org>
References: <4170B701.7060103@is.kochi-u.ac.jp>	
	<p0600200bbd966d04ed83@[24.165.137.33]>
	<1098061704.18273.28.camel@geddy.wooz.org>
Message-ID: <p06002002bd99485fbcb6@[10.241.2.247]>

At 9:08 PM -0400 2004-10-17, Barry Warsaw wrote:

>  Oh, BTW, could you (or someone) update those FAQ entries to explain my
>  intent about Python backward compatibility?  Thanks,

	If this hasn't already been done, I will do so.

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

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

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

   SAGE member since 1995.  See <http://www.sage.org/> for more info.
From brad at stop.mail-abuse.org  Mon Oct 18 12:15:51 2004
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Mon Oct 18 12:24:07 2004
Subject: [Mailman-Developers] Can we remove nimda.txt ?
In-Reply-To: <1098061650.18272.26.camel@geddy.wooz.org>
References: <4170B701.7060103@is.kochi-u.ac.jp>	
	<p0600200bbd966d04ed83@[24.165.137.33]>
	<1098061650.18272.26.camel@geddy.wooz.org>
Message-ID: <p06002001bd9946d35fbc@[10.241.2.247]>

At 9:07 PM -0400 2004-10-17, Barry Warsaw wrote:

>  As to 5.8 and 4.42, I do consider the fact that Mailman 2.1.5 breaks
>  under older Python's a bug that should be fixed in 2.1.6 (and was fixed
>  in CVS very early on).  Mailman 2.1.x should still run under Python
>  2.1.  I do however /recommend/ using Python 2.3.

	Fair enough.  We can update the FAQ Wizard entry when 2.1.6 ships.

>  As for 5.12, I think it's an oversight on my part that the bounce probe
>  feature requires VERP support in the MTA.  I would like to see the probe
>  become optional in 2.1.6 so that if you do not have VERP, Mailman will
>  process bounces in the 2.1.4 way (i.e. not send a probe).  I don't know
>  if that's feasible or even desirable -- how much pain is it for
>  mailman-users that VERP is required?  From 5.12, it sounds like those
>  using Mailman in some hosting arrangements are prevented from upgrading
>  because of this.  That's unfortunate.

	I don't know how much work it would require to make this turned 
on by default, but to allow fallback behaviour if not supported.  The 
alternative is to revert to the older behaviour and turn off the VERP 
features by default.  I'm not fond of that alternative, but it may be 
better for the broader Mailman community, especially those at hosting 
sites where more modern MTA features may not be available.

>  /Should/ we require VERP?  My preference would be "no".

	If that's the direction you prefer, that's fine.  My point is 
that we should align all our features, and if we're going to require 
VERP in one area, we might as well make use of it in another, 
especially if doing so will help to reduce a very common complaint.

>  Can you provide more detail about those complaints?  What don't people
>  like about it?  The only difference between "personalized" messages and
>  "fully personalized" messages is the To header, so if they don't like
>  that, you shouldn't fully personalize the messages.

	The munging of the To: and Cc: headers, throwing away all 
previous information that was there, etc... has been the major 
complaint that has been voiced to me.  My understanding is that some 
of the template/personalization features are not enabled unless you 
turn on "full personalization", and if that's the case, we need a 
fourth alternative.

	If I'm wrong, then we might want to be more clear in our 
documentation, so that people do not needlessly turn on full 
personalization when they don't have to do so in order to get the 
features they're looking for.

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

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

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

   SAGE member since 1995.  See <http://www.sage.org/> for more info.
From brad at stop.mail-abuse.org  Mon Oct 18 12:38:47 2004
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Mon Oct 18 12:38:58 2004
Subject: [Mailman-Developers] Can we remove nimda.txt ?
In-Reply-To: <1098061704.18273.28.camel@geddy.wooz.org>
References: <4170B701.7060103@is.kochi-u.ac.jp>	
	<p0600200bbd966d04ed83@[24.165.137.33]>
	<1098061704.18273.28.camel@geddy.wooz.org>
Message-ID: <p06002003bd994d83f0f4@[10.0.1.3]>

At 9:08 PM -0400 2004-10-17, Barry Warsaw wrote:

>  Oh, BTW, could you (or someone) update those FAQ entries to explain my
>  intent about Python backward compatibility?  Thanks,

	Okay, 5.8 and 5.12 have been updated with notes at the end, based 
on comments made in this thread.  Please let me know if you think 
there need to be changes made, or if you think they look okay.

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

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

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

   SAGE member since 1995.  See <http://www.sage.org/> for more info.
From tkikuchi at is.kochi-u.ac.jp  Mon Oct 18 14:43:31 2004
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Mon Oct 18 14:44:05 2004
Subject: [Mailman-Developers] Can we remove nimda.txt ?
In-Reply-To: <1098061650.18272.26.camel@geddy.wooz.org>
References: <4170B701.7060103@is.kochi-u.ac.jp>	
	<p0600200bbd966d04ed83@[24.165.137.33]>
	<1098061650.18272.26.camel@geddy.wooz.org>
Message-ID: <4173BA73.3030103@is.kochi-u.ac.jp>

Barry Warsaw wrote:

> As for 5.12, I think it's an oversight on my part that the bounce probe
> feature requires VERP support in the MTA.  I would like to see the probe
> become optional in 2.1.6 so that if you do not have VERP, Mailman will
> process bounces in the 2.1.4 way (i.e. not send a probe). 

Before I start working on this, does anyone have a patch?
I think we should introduce BOUNCER_USE_VERP_PROBE (or something) and
set its default to No.

>>	Also, if we're going to require VERP support on the MTA with 
>>2.1.5 and beyond, can we go ahead and turn on "VERP_CONFIRMATIONS = 
>>Yes" in mm_cfg.py, so that we can also eliminate all the questions 
>>regarding the funky subject lines which led to FAQ 4.52?
> 
> 
> /Should/ we require VERP?  My preference would be "no".

OK Barry, we should step back. I want however to introduce patch 923428
so site admin can use full feature of VERP_CONFIRMATIONS.

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

From tkikuchi at is.kochi-u.ac.jp  Mon Oct 18 15:02:49 2004
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Mon Oct 18 15:03:03 2004
Subject: [Mailman-Developers] small scubber issue
In-Reply-To: <C23E51EF1A400A39C69AF668@lewes.staff.uscs.susx.ac.uk>
References: <20041016130726.GA29607@rezo.net>
	<4171C287.3010701@is.kochi-u.ac.jp>
	<C23E51EF1A400A39C69AF668@lewes.staff.uscs.susx.ac.uk>
Message-ID: <4173BEF9.2020505@is.kochi-u.ac.jp>

> 
> Does the scrubber wrap the URLs in angle brackets, per the appendix to 
> rfc 1738?
> 

No. Scrubber.py is originally written for the pipermail archiver. So, it
was enough not wrapping. But, I think URL parsing of MUA is an optional
feature and there is no standard. My Netscape mailer always add trailing
japanese character (such as full width space) and return 404 when I
click on a link. I don't want to add extra cr/lf in scrubbed message so 
try adding a blank line before the footer separator if someone
complains.

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

From gustavorfranco at gmail.com  Mon Oct 18 15:27:24 2004
From: gustavorfranco at gmail.com (Gustavo Franco)
Date: Mon Oct 18 15:27:27 2004
Subject: [Mailman-Developers] Maximum number of members per list. [was:
	Can we remove nimda.txt ?]
In-Reply-To: <1098061974.18277.32.camel@geddy.wooz.org>
References: <4170B701.7060103@is.kochi-u.ac.jp>
	<5fabd6fd041016204825cb3a36@mail.gmail.com>
	<1098061974.18277.32.camel@geddy.wooz.org>
Message-ID: <5fabd6fd041018062761bcef02@mail.gmail.com>

On Sun, 17 Oct 2004 21:12:54 -0400, Barry Warsaw <barry@python.org> wrote:
> On Sat, 2004-10-16 at 23:48, Gustavo Franco wrote:
> 
> > Anyone cares about 1029275 (Maximum number of members per list) ? This
> > patch was submitted at sf and here a month ago and still nothing. I
> > just want to read "we don't want this feature" or "it's a bad patch,
> > it's needs more work here and there". Kikuchi ?
> 
> I'm not personally in favor of adding this feature to the 2.1 line.  I
> understand that because 2.2 will never come out and I'm way behind on
> 3.0 that pressure builds to add new features to the 2.1 point releases.
> I'd still like to resist that pressure as much as possible, but I can
> support getting some new features (in a backward compatible way) into
> 2.1.(x>5).  Let's take them on a case-by-case basis (and Tokio has a lot
> of sway here because he's doing the hard work ;).
 
I understand your point and Tokio replied me at sf. Do you think that
is a feature that can be included on 3.0 ? I can keep extending it
over 2.1 line (updating 1029275) and add it to 3.0 tree. I'm not into
mailman project to deep (yet) but i'll read that page about mm3 at
zope.org now.

What's your opinion on distributors adding new features to mailman 2.1
packages? Considering that 3.0 won't be released soon is a good idea
announce that hot new features won't be added if not really needed on
mm2.1 tree, isn't it? jmo.

Thanks,
Gustavo Franco -- <stratus@acm.org>
From bob at nleaudio.com  Mon Oct 18 16:15:56 2004
From: bob at nleaudio.com (Bob Puff@NLE)
Date: Mon Oct 18 16:19:21 2004
Subject: [Mailman-Developers] on the subject of fix_url,	list creation
	with @ is non-intuitive..
In-Reply-To: <773259D9-20CF-11D9-AF51-000D934FBF38@zone12.com>
References: <20041011174016.GA5462@meer.net>	<PC17102004101111473702038a58cbd0@msapiro>	<20041012031057.GA14331@meer.net>	<A7F8452C-2090-11D9-AE96-000D934FBF38@zone12.com>	<20041018004118.M81461@nleaudio.com>
	<773259D9-20CF-11D9-AF51-000D934FBF38@zone12.com>
Message-ID: <4173D01C.9090302@nleaudio.com>

Hi Terri,

If your list machine isn't the same box as the webserver machine, then the web-based create isn't 
going to work.  :-)  I still think it makes sense.

Bob

Terri Oda wrote:

> On Oct 17, 2004, at 8:43 PM, Bob Puff wrote:
> 
>> Hmm I guess I still don't get why "name@domain" is confusing, because 
>> that
>> -is- the posting address of the list!  If you want to add another 
>> field for
>> domain, that's fine; but I think the current behaviour makes sense.
> 
> 
> Is it always the posting address, though?  If you create a list:
> 
> mylist@www.example.com
> 
> isn't it possible that www.example.com is just a webserver and the mail 
> is actually handled by some other domain (eg: lists.example.com) which 
> may not be the same machine?
> 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Unsubscribe: 
> http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com 
> 
> 
From jdennis at redhat.com  Mon Oct 18 17:18:05 2004
From: jdennis at redhat.com (John Dennis)
Date: Mon Oct 18 17:18:14 2004
Subject: [Mailman-Developers] this mail-gid problem
In-Reply-To: <20041016083009.GI21335@rezo.net>
References: <20041016083009.GI21335@rezo.net>
Message-ID: <1098112685.9340.56.camel@finch.boston.redhat.com>

On Sat, 2004-10-16 at 04:30, Fil wrote:
> I would like to know if this check can be expanded to list all GID that
> mailman will accept? Or if I should just be more carful in setting up my
> system? :)

We patch mailman to accept multiple GID's. The patch is attached. It
includes changes to configure to accept a list of GID's so don't forget
if you apply the patch you'll have to run autoconf to generate a new
configure.

BTW, the preferred solution as you allude to is to be rigorous with the
identity and permissions of system components. This patch is more of a
concession to the dilemma of distributing mailman in an environment
where other packages and configurations may be installed which are
beyond our control than a suggested approach. Ideally this would not be
necessary and for what its worth I have some misgivings about it. Our
distribution is moving to a more constrained set of packages and much
more security driven. This patch which has been in our RPM for a while
is on the table for removal because of these security concerns.
-- 
John Dennis <jdennis@redhat.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mailman-2.1-multimail.patch
Type: text/x-patch
Size: 14094 bytes
Desc: not available
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20041018/6520702e/mailman-2.1-multimail-0001.bin
From terri at zone12.com  Mon Oct 18 18:41:19 2004
From: terri at zone12.com (Terri Oda)
Date: Mon Oct 18 18:41:24 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <4173D01C.9090302@nleaudio.com>
References: <20041011174016.GA5462@meer.net>	<PC17102004101111473702038a58cbd0@msapiro>	<20041012031057.GA14331@meer.net>	<A7F8452C-2090-11D9-AE96-000D934FBF38@zone12.com>	<20041018004118.M81461@nleaudio.com>
	<773259D9-20CF-11D9-AF51-000D934FBF38@zone12.com>
	<4173D01C.9090302@nleaudio.com>
Message-ID: <89995ECA-2124-11D9-A1B6-000D934FBF38@zone12.com>

On Oct 18, 2004, at 10:15 AM, Bob Puff@NLE wrote:
> If your list machine isn't the same box as the webserver machine, then 
> the web-based create isn't going to work.  :-)  I still think it makes 
> sense.

Good point -- I'd forgotten we were still talking about web based 
creation.  I was making man pages for the stuff in bin/ earlier this 
month, and the name@www.domain syntax is the same even when you're 
working from the shell, and that's where I don't think it necessarily 
makes sense.

  Terri

From bob at nleaudio.com  Mon Oct 18 20:49:44 2004
From: bob at nleaudio.com (Bob Puff@NLE)
Date: Mon Oct 18 20:53:04 2004
Subject: [Mailman-Developers] on the subject of fix_url,	list creation
	with @ is non-intuitive..
In-Reply-To: <89995ECA-2124-11D9-A1B6-000D934FBF38@zone12.com>
References: <20041011174016.GA5462@meer.net>	<PC17102004101111473702038a58cbd0@msapiro>	<20041012031057.GA14331@meer.net>	<A7F8452C-2090-11D9-AE96-000D934FBF38@zone12.com>	<20041018004118.M81461@nleaudio.com>	<773259D9-20CF-11D9-AF51-000D934FBF38@zone12.com>	<4173D01C.9090302@nleaudio.com>
	<89995ECA-2124-11D9-A1B6-000D934FBF38@zone12.com>
Message-ID: <41741048.4080601@nleaudio.com>

Right.  But when would you use a www.domain?  I never use www.  Do people name their box www?  I 
usually name the host something else.  I think most people are smart enough to figure out that 
list_name@domain is not list_name@www.domain.  You face the exact same problem of people doing the 
same things with two different parameters; i.e., bin/create list_name www.domain etc...

Whatever, its not a big deal, as long as the create script still works with the old syntax (which 
was my original point).

Bob

Terri Oda wrote:

> On Oct 18, 2004, at 10:15 AM, Bob Puff@NLE wrote:
> 
>> If your list machine isn't the same box as the webserver machine, then 
>> the web-based create isn't going to work.  :-)  I still think it makes 
>> sense.
> 
> 
> Good point -- I'd forgotten we were still talking about web based 
> creation.  I was making man pages for the stuff in bin/ earlier this 
> month, and the name@www.domain syntax is the same even when you're 
> working from the shell, and that's where I don't think it necessarily 
> makes sense.
> 
>  Terri
> 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Unsubscribe: 
> http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com 
> 
> 
From jdennis at redhat.com  Mon Oct 18 22:26:21 2004
From: jdennis at redhat.com (John Dennis)
Date: Mon Oct 18 22:26:25 2004
Subject: [Mailman-Developers] FHS installation changes
Message-ID: <1098131181.9340.103.camel@finch.boston.redhat.com>

Overview:
---------

Earlier I wrote about our (Red Hat's) desire to make mailman be FHS
compliant, in part to allow mailman to fall under the protection of
SELinux security policy which is file and directory based and as a
consequence much easier to author when packages install into canonical
locations (e.g. FHS).

Previously we had installed all of mailman under /var/mailman
(prefix=var_prefix=/var/mailman) and I had proposed a much simpler
change of just setting prefix=/usr/lib/mailman. This took care of the
majority of SELinux issues and limited the scope of changes. There was
a concern that sites and administrators who were familiar either with
our RPM, the upstream package, or were working with an existing
installation would run afoul of the location changes and keeping them
to absolute minimum was advantageous. However a few folks in private
email pointed out that if changes were going to occur its best to do
it all at once and not piecemeal, in other words endure the pain once.

Thus I embarked on an exercise to make everything FHS compliant. There
are two reasons I'm addressing the developer community here:

1) I want to apprise you of the exact changes, their rational, provide
   a patch against 2.1.5 and solicit review.

2) Test the results.

Description:
------------

Currently the configuration allows for partitioning the mailman
installation between two installation roots, prefix for non-modifiable
files and var_prefix for variable data. This is a great start and
covers 90% of the installation, but there remains a small set of items
which even in this scheme are not FHS compliant, in summary:

1) config files located under /etc

2) pid file located under /var/run

3) queue files located under /var/spool

4) lock files located /var/lock

5) log files located under /var/log

I think one could characterize the competing installation philosophies
as follows:

Mailman not knowing what type of system its going to be installed on
elects to group all of its files together (makes perfect sense). FHS
on the other hand says most packages share common traits and we group
by functional component thus spreading out package installations
across a diverse set of directories.

Implementation:
---------------

I discovered I had to add some new directories to configure and alter
some of the *_DIR variables in Defaults.py.in so they pick up their
values from configure. My strategy was to allow configure when run
without providing any other parameters to produce the exact same set
of installation defaults as previously existed so unless you specify a
different installation mapping a user won't see any change.

Configure added:

--with_lock_dir
--with_log_dir
--with_config_dir
--with_data_dir
--with_pid_dir
--with_queue_dir

I also modified bin/check_perms so it was aware of the new directory
specifications. The patch also made a few non FHS fixes to the install
target of the Makefiles, some generic issues were discovered when
testing check_perms. Those changes included: setting SETGID on the root
prefix and var_prefix directories, check_perms demands all
directories, including the roots are SETGID. The messages Makefile was
creating a two level directory hierarchy but only setting SETGID on
the child. Some of the "make install" logic seemed to depend on the
property that new child directories created under a parent that was
SETGID inherits the SETGID property. To the best of my understanding
this is true only on Linux and Solaris and not generally portable. I
replaced the use of the local mkinstalldirs (and subsequent chmod g+s)
with what I believe is much more standard "install -d" and with the
SETGID as part of the mode. All directories are created this way,
nothing depends on inheritance. I also removed some ancient Makefile
cruft that is no longer in use, variables no longer initialized by
configure, etc. (just confusing, accidents waiting to happen if
someone thought it was valid).

Issues:
-------

Most of the changes were isolated to whole directories and were well
defined. Only the contents of DATA_DIR required splitting its contents
across more than one directory. DATA_DIR contained both pickle files
created during processing and what would be characterized as
configuration files (e.g. password files, MTA alias
files. sitelist.cfg). A new directory CONFIG_DIR was created (in FHS
its /etc/mailman) to hold what has traditionally been in /etc
(e.g. configuration, passwords, aliases, etc). The other things that
were in DATA_DIR was left there.

The mailman configuration file presented the biggest challenge and the
one exception to FHS. The culprit is mm_cfg.py. This is really
mailman's configuration file and it should be located in CONFIG_DIR
(/etc/mailman). But there were several major problems with moving that
file there.

1) It's executable python code, not a text file containing
   configuration parameters. Executable code should be in a "lib" or
   "bin" location. Why is this an issue? Because SELinux pays very
   close attention to who can execute and with precise control over a
   host of run time operations, its often based on directory
   location. But most importantly config files have to be editable,
   security properties transit when modified and new files pick up
   security properties of the directory that contains the file. We do
   not want any file created (or modified) in a configuration
   directory to pick up security permissions granting execution
   rights or for that matter any other run time security permissions.

2) The import of mm_cfg and its directory (Mailman) is all through the
   code, it would be very invasive to change. If mm_cfg continues to be
   executable python code as opposed to a text file then paths.py
   would have to be altered to prepend /etc/mailman to the import
   path, another significant security violation.

3) Any experienced mailman admin will know that mm_cfg.py is located
   with the rest of the mailman executable code under $prefix/Mailman
   and will expect to find this critical file there.

I concluded for the above reasons that mm_cfg.py in the 2.1.x
time frame was best handled as an FHS exception. Our rpm does however
create a symbolic link from /etc/mailman/mm_cfg.py to
$prefix/Mailman/mm_cfg.py so that it "appears" in configuration
directory. This will prepare admins to start looking for mm_cfg along
with the other configuration files. Note that security policies do not
transit across links therefore there are no security policy issues
with the sym link in /etc/mailman. Hopefully in MM 3.0 the
configuration file will be textural which will eliminate the security
policy issue. Also note that sitelist.cfg was completely moved to
/etc/mailman as that is not executed, but rather "evaluated" (I think
evaluation in /etc is fine, but I'm not 100% positive :-).

Request for testing:
--------------------

I have created RPM's with the changes outlined above and documented
below, you may obtain them here:

ftp://people.redhat.com/jdennis/mailman-2.1.5-26.i386.rpm
ftp://people.redhat.com/jdennis/mailman-2.1.5-26.src.rpm

I have tested the new rpm and have not found any problems. The
modified check_perms does not report any problems. But I'm well aware
my testing is limited and my comprehension of mailman is limited, it
is inevitable something has been missed that only wider testing will
reveal and I would appreciate that testing by experts. These changes
are slated to appear in our Fedora Core 3 release which is closing in
a couple of days in preparation for release. Testing prior to that
close would be appreciated. Note that with Fedora Core 3 SELinux will
be enabled by default in "targeted mode". This means that SELinux
policy will be applied to key system services only, mail and hence
mailman is one of those key system services. Ideally any testing
should be done from "rawhide" with the 2.1.5-26 version of mailman and
the new matching SELinux security policy, but I would be perfectly
happy for any testing of the basic rpm even if its not running under
targeted security policy.

Patch File:
-----------

Attached is the patch made against a virgin 2.1.5 tarball with the
changes outlined above.


User / Admin Documentation:
---------------------------

The following is what I prepared for our installation documentation
which can be found in /usr/share/doc/mailman-*



IMPORTANT NOTE FOR USERS UPGRADING FROM A PREVIOUS RED HAT MAILMAN
INSTALLATION OR THOSE FAMILIAR WITH "STANDARD MAILMAN INSTALLATIONS"

    Earlier Red Hat mailman rpms installed all of the mailman files under
    /var/mailman. This did not conform to the Filesystem Hierarchy
    Standard (FHS) and created security violations when SELinux is
    enabled. As of mailman-2.1.5-21 the following directory and file
    changes occurred:

    variable data (e.g. lists) is in /var/lib/mailman, library code,
    executables, and scripts are located in /usr/lib/mailman, lock files are in
    /var/lock/mailman, the pid file is in /var/run/mailman, qfiles are in /var/spool/mailman,
    and configuration files have been moved to the new /etc/mailman

    If you previously had mailman installed and have edited files in
    /var/mailman (e.g. configuration) you will need to move those changes
    to their new locations.

    The mapping of old locations to new locations is as follows:

    Directory Mapping:
    /var/mailman				--> /var/lib/mailman
    /var/mailman/Mailman			--> /usr/lib/mailman/Mailman
    /var/mailman/archives			--> /var/lib/mailman/archives
    /var/mailman/bin				--> /usr/lib/mailman/bin
    /var/mailman/cgi-bin			--> /usr/lib/mailman/cgi-bin
    /var/mailman/cron				--> /usr/lib/mailman/cron
    /var/mailman/data				--> /var/lib/mailman/data
    /var/mailman/lists				--> /var/lib/mailman/lists
    /var/mailman/locks				--> /var/lock/mailman
    /var/mailman/logs				--> /var/log/mailman
    /var/mailman/mail				--> /usr/lib/mailman/mail
    /var/mailman/messages			--> /usr/lib/mailman/messages
    /var/mailman/pythonlib			--> /usr/lib/mailman/pythonlib
    /var/mailman/qfiles				--> /var/spool/mailman
    /var/spool/mailman/qfiles			--> /var/spool/mailman
    /var/mailman/scripts			--> /usr/lib/mailman/scripts
    /var/mailman/spam				--> /var/lib/mailman/spam
    /var/mailman/templates			--> /usr/lib/mailman/templates
    /var/mailman/tests				--> /usr/lib/mailman/tests

    File Mapping:
    /var/mailman/data/adm.pw			--> /etc/mailman/adm.pw
    /var/mailman/data/creator.pw		--> /etc/mailman/creator.pw
    /var/mailman/data/aliases			--> /etc/mailman/aliases
    /var/mailman/data/virtual-mailman		--> /etc/mailman/virtual-mailman
    /var/mailman/data/sitelist.cfg		--> /etc/mailman/sitelist.cfg
    /var/mailman/data/master-qrunner.pid	--> /var/run/mailman/master-qrunner.pid

    Discussion of directory and file relocation:

    Two new directories were created and three existing directories which
    were hardcoded are now configurable.

    PID_DIR is used to hold the process id and is new because FHS wants
    pid files to be located in /var/run. The FHS says when there is only a
    single pid file it should be located in /var/run/<name>.pid, and when
    there are multiple pid's files they should be located together in a
    subdirectory, /var/run/<name>/. Currently mailman only has a single
    pid file, but it does have multiple processes (qrunners). Also SELinux
    security policy is easier to write if processes are segregated into
    individual subdirectories. Therefore we elected to place the mailman
    pid file in its own subdirectory, there is some debate if this is 100%
    FHS compliant because there is only currently a single pid file, but
    this gives us greater future flexibility and is in the spirit of FHS.

    CONFIG_DIR is used to hold the site configuration files. FHS wants
    configuration files stored in /etc/mailman. Previously configuration
    files were mixed in with data files in DATA_DIR and with the run-time
    code (e.g. Mailman/mm_cfg.py). CONFIG_DIR continues to exist but is
    now restricted to data files (e.g. python pickle files). The password
    files, alias files, and .cfg (e.g. sitelist.cfg) files have been moved
    to CONFIG_DIR. mm_cfg.py which is the primary mailman configuration
    file was presented a bit of a dilemma. In theory it should be located
    in /etc/mailman, however it is executable code which argues it should
    be located with the other executable files, it has traditionally lived
    in $PREFIX/Mailman and experienced mailman admins will expect to find
    it there. Modifying all the mm_cfg import statements and paths.py was
    believed to be too invasive a change, and technically its part of the
    "Mailman" package and moving it would take it out of the package
    (although currently I don't think that presents any known
    issues). Instead a compromise approach was adopted, mm_cfg.py is
    symbolically linked into the /etc/mailman directory pointing to
    $PREFIX/Mailman/mm_cfg.py. Thus mm_cfg.py "appears" in the
    configuration directory but retains its traditional location, this was
    deemed a reasonable compromise for the mailman 2.1.x timeframe.

    sitelist.cfg has a symbolic link in its old location in the DATA_DIR
    pointing to its new location in the CONFIG_DIR.

    New Directories (can be specified as parameter to configure):

    CONFIG_DIR:	default=$VAR_PREFIX/data		FHS=/etc/mailman
    PID_DIR	default=$VAR_PREFIX/data		FHS=/var/run/mailman

    Existing directories that can now be specified as parameter to configure:

    LOCK_DIR:	default=$VAR_PREFIX/locks	FHS=/var/lock/mailman
    LOG_DIR:	default=$VAR_PREFIX/logs	FHS=/var/log/mailman
    QUEUE_DIR	default=$VAR_PREFIX/qfiles	FHS=/var/spool/mailman


-- 
John Dennis <jdennis@redhat.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mailman-FHS.patch
Type: text/x-patch
Size: 9098 bytes
Desc: not available
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20041018/2dc77862/mailman-FHS-0001.bin
From miranda at uranus.com  Mon Oct 18 22:47:37 2004
From: miranda at uranus.com (Michael Chang)
Date: Mon Oct 18 22:47:49 2004
Subject: [Mailman-Developers] on the subject of fix_url, list creation
	with @ is non-intuitive..
In-Reply-To: <4173D01C.9090302@nleaudio.com>
Message-ID: <Pine.LNX.4.44.0410181643160.22208-100000@ion.uranus.com>


|> If your list machine isn't the same box as the webserver machine, then
|> the web-based create isn't going to work.  :-)

Unless the webserver is mounting the list machine's Mailman installation
via NFS.

I think that if you want a fair compromise, then require a '--posting-address='
argument to `newlist' that accepts the xxx@xxx-style declaration.
Otherwise, by default, it parses the arguments like '<name> <listname>'.

Michael


|> Terri Oda wrote:
|> 
|> > On Oct 17, 2004, at 8:43 PM, Bob Puff wrote:
|> > 
|> >> Hmm I guess I still don't get why "name@domain" is confusing, because 
|> >> that
|> >> -is- the posting address of the list!  If you want to add another 
|> >> field for
|> >> domain, that's fine; but I think the current behaviour makes sense.
|> > 
|> > 
|> > Is it always the posting address, though?  If you create a list:
|> > 
|> > mylist@www.example.com
|> > 
|> > isn't it possible that www.example.com is just a webserver and the mail 
|> > is actually handled by some other domain (eg: lists.example.com) which 
|> > may not be the same machine?
|> > 
|> > _______________________________________________
|> > Mailman-Developers mailing list
|> > Mailman-Developers@python.org
|> > http://mail.python.org/mailman/listinfo/mailman-developers
|> > Unsubscribe: 
|> > http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com 
|> > 
|> > 
|> _______________________________________________
|> Mailman-Developers mailing list
|> Mailman-Developers@python.org
|> http://mail.python.org/mailman/listinfo/mailman-developers
|> Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/miranda%40uranus.com
|> 

-- 
/* BEGIN SIG
 *
 * "Afraid of change, afraid of staying the same,
 *  when temptation calls, we just look away."
 *  - Barenaked Ladies
 *
 *-----------------------------
 * Michael Chang
 * miranda [at] uranus dot com
 * AIM: Solempathe
 * http://www.syndetic.org/
 */

From jwblist at olympus.net  Tue Oct 19 01:55:56 2004
From: jwblist at olympus.net (John W. Baxter)
Date: Tue Oct 19 01:56:04 2004
Subject: [Mailman-Developers] Can we remove nimda.txt ?
In-Reply-To: <20041016171335.27719baf@osage.osagesoftware.com>
Message-ID: <BD99A61C.17618%jwblist@olympus.net>

On 10/16/2004 14:13, "David Relson" <relson@osagesoftware.com> wrote:

> On Sat, 16 Oct 2004 08:52:15 -0700
> John W. Baxter wrote:
> 
> ...[snip]...
> 
>> You might want to refer folks who want to run test "virus" messages
>> through their Mailman system ("system" = the MTA and its filtering and
>> Mailman and whatever else is involved at a given site) to
>>    http://www.eicar.org
>> (note...eicar.com is very different).
> 
> They are??? www.eicar.org and www.eicar.com look identical (and have the
> same IP address).
> 

Oops...they are the same.

This was Safari helpfully completing a URL it had seen before within
eicar.org, and not completing it--not having see it--in eicar.com.

The proper reference would probably be the more complete

eicar.org/anti_virus_test_file.htm
or
eicar.com/anti_virus_test_file.htm

Thanks for objecting!  ;-)

  --John
From msapiro at value.net  Tue Oct 19 04:58:58 2004
From: msapiro at value.net (Mark Sapiro)
Date: Tue Oct 19 04:59:16 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creationwith @ is non-intuitive..
In-Reply-To: <41741048.4080601@nleaudio.com>
Message-ID: <PC1710200410181958580609166070bb@msapiro>

Bob Puff wrote:

>Right.  But when would you use a www.domain?  I never use www.  Do people name their box www?  I 
>usually name the host something else.  I think most people are smart enough to figure out that 
>list_name@domain is not list_name@www.domain.  You face the exact same problem of people doing the 
>same things with two different parameters; i.e., bin/create list_name www.domain etc...
>
>Whatever, its not a big deal, as long as the create script still works with the old syntax (which 
>was my original point).
>

Actually, when you create a list via the web, the host name of the web
create URL is hostname in

   mlist.web_page_url = mm_cfg.DEFAULT_URL_PATTERN % hostname

and id is looked up in VIRTUAL_HOSTS to get emailhost for

   mlist.host_name = emailhost


Likewise, in

  bin/newlist listname@hostname

Thus, for bin/newlist listname@hostname is likely not the e-mail
address of the list. Or, if listname@hostname is the intended e-mail
posting address of the list,

  bin/newlist listname@hostname

is probably not the way you want to create it, at least in any
installation where VIRTUAL_HOST_OVERVIEW has the default "true" value.

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

 
>
>Terri Oda wrote:
>
>> On Oct 18, 2004, at 10:15 AM, Bob Puff@NLE wrote:
>> 
>>> If your list machine isn't the same box as the webserver machine, then 
>>> the web-based create isn't going to work.  :-)  I still think it makes 
>>> sense.
>> 
>> 
>> Good point -- I'd forgotten we were still talking about web based 
>> creation.  I was making man pages for the stuff in bin/ earlier this 
>> month, and the name@www.domain syntax is the same even when you're 
>> working from the shell, and that's where I don't think it necessarily 
>> makes sense.
>> 
>>  Terri

From bob at nleaudio.com  Tue Oct 19 06:20:20 2004
From: bob at nleaudio.com (Bob Puff@NLE)
Date: Tue Oct 19 06:24:13 2004
Subject: [Mailman-Developers] FHS installation changes
In-Reply-To: <1098131181.9340.103.camel@finch.boston.redhat.com>
References: <1098131181.9340.103.camel@finch.boston.redhat.com>
Message-ID: <41749604.7030409@nleaudio.com>

John makes some really valid points here.  While it is a bit more of a change, FHS compatibility 
does make sense.  Is this something that we can consider for future 2.1.x releases?

Bob

John Dennis wrote:

> Overview:
> ---------
> 
> Earlier I wrote about our (Red Hat's) desire to make mailman be FHS
> compliant, in part to allow mailman to fall under the protection of
> SELinux security policy which is file and directory based and as a
> consequence much easier to author when packages install into canonical
> locations (e.g. FHS).
> 
> Previously we had installed all of mailman under /var/mailman
> (prefix=var_prefix=/var/mailman) and I had proposed a much simpler
> change of just setting prefix=/usr/lib/mailman. This took care of the
> majority of SELinux issues and limited the scope of changes. There was
> a concern that sites and administrators who were familiar either with
> our RPM, the upstream package, or were working with an existing
> installation would run afoul of the location changes and keeping them
> to absolute minimum was advantageous. However a few folks in private
> email pointed out that if changes were going to occur its best to do
> it all at once and not piecemeal, in other words endure the pain once.
> 
> Thus I embarked on an exercise to make everything FHS compliant. There
> are two reasons I'm addressing the developer community here:
> 
> 1) I want to apprise you of the exact changes, their rational, provide
>    a patch against 2.1.5 and solicit review.
> 
> 2) Test the results.
> 
> Description:
> ------------
> 
> Currently the configuration allows for partitioning the mailman
> installation between two installation roots, prefix for non-modifiable
> files and var_prefix for variable data. This is a great start and
> covers 90% of the installation, but there remains a small set of items
> which even in this scheme are not FHS compliant, in summary:
> 
> 1) config files located under /etc
> 
> 2) pid file located under /var/run
> 
> 3) queue files located under /var/spool
> 
> 4) lock files located /var/lock
> 
> 5) log files located under /var/log
> 
> I think one could characterize the competing installation philosophies
> as follows:
> 
> Mailman not knowing what type of system its going to be installed on
> elects to group all of its files together (makes perfect sense). FHS
> on the other hand says most packages share common traits and we group
> by functional component thus spreading out package installations
> across a diverse set of directories.
> 
> Implementation:
> ---------------
> 
> I discovered I had to add some new directories to configure and alter
> some of the *_DIR variables in Defaults.py.in so they pick up their
> values from configure. My strategy was to allow configure when run
> without providing any other parameters to produce the exact same set
> of installation defaults as previously existed so unless you specify a
> different installation mapping a user won't see any change.
> 
> Configure added:
> 
> --with_lock_dir
> --with_log_dir
> --with_config_dir
> --with_data_dir
> --with_pid_dir
> --with_queue_dir
> 
> I also modified bin/check_perms so it was aware of the new directory
> specifications. The patch also made a few non FHS fixes to the install
> target of the Makefiles, some generic issues were discovered when
> testing check_perms. Those changes included: setting SETGID on the root
> prefix and var_prefix directories, check_perms demands all
> directories, including the roots are SETGID. The messages Makefile was
> creating a two level directory hierarchy but only setting SETGID on
> the child. Some of the "make install" logic seemed to depend on the
> property that new child directories created under a parent that was
> SETGID inherits the SETGID property. To the best of my understanding
> this is true only on Linux and Solaris and not generally portable. I
> replaced the use of the local mkinstalldirs (and subsequent chmod g+s)
> with what I believe is much more standard "install -d" and with the
> SETGID as part of the mode. All directories are created this way,
> nothing depends on inheritance. I also removed some ancient Makefile
> cruft that is no longer in use, variables no longer initialized by
> configure, etc. (just confusing, accidents waiting to happen if
> someone thought it was valid).
> 
> Issues:
> -------
> 
> Most of the changes were isolated to whole directories and were well
> defined. Only the contents of DATA_DIR required splitting its contents
> across more than one directory. DATA_DIR contained both pickle files
> created during processing and what would be characterized as
> configuration files (e.g. password files, MTA alias
> files. sitelist.cfg). A new directory CONFIG_DIR was created (in FHS
> its /etc/mailman) to hold what has traditionally been in /etc
> (e.g. configuration, passwords, aliases, etc). The other things that
> were in DATA_DIR was left there.
> 
> The mailman configuration file presented the biggest challenge and the
> one exception to FHS. The culprit is mm_cfg.py. This is really
> mailman's configuration file and it should be located in CONFIG_DIR
> (/etc/mailman). But there were several major problems with moving that
> file there.
> 
> 1) It's executable python code, not a text file containing
>    configuration parameters. Executable code should be in a "lib" or
>    "bin" location. Why is this an issue? Because SELinux pays very
>    close attention to who can execute and with precise control over a
>    host of run time operations, its often based on directory
>    location. But most importantly config files have to be editable,
>    security properties transit when modified and new files pick up
>    security properties of the directory that contains the file. We do
>    not want any file created (or modified) in a configuration
>    directory to pick up security permissions granting execution
>    rights or for that matter any other run time security permissions.
> 
> 2) The import of mm_cfg and its directory (Mailman) is all through the
>    code, it would be very invasive to change. If mm_cfg continues to be
>    executable python code as opposed to a text file then paths.py
>    would have to be altered to prepend /etc/mailman to the import
>    path, another significant security violation.
> 
> 3) Any experienced mailman admin will know that mm_cfg.py is located
>    with the rest of the mailman executable code under $prefix/Mailman
>    and will expect to find this critical file there.
> 
> I concluded for the above reasons that mm_cfg.py in the 2.1.x
> time frame was best handled as an FHS exception. Our rpm does however
> create a symbolic link from /etc/mailman/mm_cfg.py to
> $prefix/Mailman/mm_cfg.py so that it "appears" in configuration
> directory. This will prepare admins to start looking for mm_cfg along
> with the other configuration files. Note that security policies do not
> transit across links therefore there are no security policy issues
> with the sym link in /etc/mailman. Hopefully in MM 3.0 the
> configuration file will be textural which will eliminate the security
> policy issue. Also note that sitelist.cfg was completely moved to
> /etc/mailman as that is not executed, but rather "evaluated" (I think
> evaluation in /etc is fine, but I'm not 100% positive :-).
> 
> Request for testing:
> --------------------
> 
> I have created RPM's with the changes outlined above and documented
> below, you may obtain them here:
> 
> ftp://people.redhat.com/jdennis/mailman-2.1.5-26.i386.rpm
> ftp://people.redhat.com/jdennis/mailman-2.1.5-26.src.rpm
> 
> I have tested the new rpm and have not found any problems. The
> modified check_perms does not report any problems. But I'm well aware
> my testing is limited and my comprehension of mailman is limited, it
> is inevitable something has been missed that only wider testing will
> reveal and I would appreciate that testing by experts. These changes
> are slated to appear in our Fedora Core 3 release which is closing in
> a couple of days in preparation for release. Testing prior to that
> close would be appreciated. Note that with Fedora Core 3 SELinux will
> be enabled by default in "targeted mode". This means that SELinux
> policy will be applied to key system services only, mail and hence
> mailman is one of those key system services. Ideally any testing
> should be done from "rawhide" with the 2.1.5-26 version of mailman and
> the new matching SELinux security policy, but I would be perfectly
> happy for any testing of the basic rpm even if its not running under
> targeted security policy.
> 
> Patch File:
> -----------
> 
> Attached is the patch made against a virgin 2.1.5 tarball with the
> changes outlined above.
> 
> 
> User / Admin Documentation:
> ---------------------------
> 
> The following is what I prepared for our installation documentation
> which can be found in /usr/share/doc/mailman-*
> 
> 
> 
> IMPORTANT NOTE FOR USERS UPGRADING FROM A PREVIOUS RED HAT MAILMAN
> INSTALLATION OR THOSE FAMILIAR WITH "STANDARD MAILMAN INSTALLATIONS"
> 
>     Earlier Red Hat mailman rpms installed all of the mailman files under
>     /var/mailman. This did not conform to the Filesystem Hierarchy
>     Standard (FHS) and created security violations when SELinux is
>     enabled. As of mailman-2.1.5-21 the following directory and file
>     changes occurred:
> 
>     variable data (e.g. lists) is in /var/lib/mailman, library code,
>     executables, and scripts are located in /usr/lib/mailman, lock files are in
>     /var/lock/mailman, the pid file is in /var/run/mailman, qfiles are in /var/spool/mailman,
>     and configuration files have been moved to the new /etc/mailman
> 
>     If you previously had mailman installed and have edited files in
>     /var/mailman (e.g. configuration) you will need to move those changes
>     to their new locations.
> 
>     The mapping of old locations to new locations is as follows:
> 
>     Directory Mapping:
>     /var/mailman				--> /var/lib/mailman
>     /var/mailman/Mailman			--> /usr/lib/mailman/Mailman
>     /var/mailman/archives			--> /var/lib/mailman/archives
>     /var/mailman/bin				--> /usr/lib/mailman/bin
>     /var/mailman/cgi-bin			--> /usr/lib/mailman/cgi-bin
>     /var/mailman/cron				--> /usr/lib/mailman/cron
>     /var/mailman/data				--> /var/lib/mailman/data
>     /var/mailman/lists				--> /var/lib/mailman/lists
>     /var/mailman/locks				--> /var/lock/mailman
>     /var/mailman/logs				--> /var/log/mailman
>     /var/mailman/mail				--> /usr/lib/mailman/mail
>     /var/mailman/messages			--> /usr/lib/mailman/messages
>     /var/mailman/pythonlib			--> /usr/lib/mailman/pythonlib
>     /var/mailman/qfiles				--> /var/spool/mailman
>     /var/spool/mailman/qfiles			--> /var/spool/mailman
>     /var/mailman/scripts			--> /usr/lib/mailman/scripts
>     /var/mailman/spam				--> /var/lib/mailman/spam
>     /var/mailman/templates			--> /usr/lib/mailman/templates
>     /var/mailman/tests				--> /usr/lib/mailman/tests
> 
>     File Mapping:
>     /var/mailman/data/adm.pw			--> /etc/mailman/adm.pw
>     /var/mailman/data/creator.pw		--> /etc/mailman/creator.pw
>     /var/mailman/data/aliases			--> /etc/mailman/aliases
>     /var/mailman/data/virtual-mailman		--> /etc/mailman/virtual-mailman
>     /var/mailman/data/sitelist.cfg		--> /etc/mailman/sitelist.cfg
>     /var/mailman/data/master-qrunner.pid	--> /var/run/mailman/master-qrunner.pid
> 
>     Discussion of directory and file relocation:
> 
>     Two new directories were created and three existing directories which
>     were hardcoded are now configurable.
> 
>     PID_DIR is used to hold the process id and is new because FHS wants
>     pid files to be located in /var/run. The FHS says when there is only a
>     single pid file it should be located in /var/run/<name>.pid, and when
>     there are multiple pid's files they should be located together in a
>     subdirectory, /var/run/<name>/. Currently mailman only has a single
>     pid file, but it does have multiple processes (qrunners). Also SELinux
>     security policy is easier to write if processes are segregated into
>     individual subdirectories. Therefore we elected to place the mailman
>     pid file in its own subdirectory, there is some debate if this is 100%
>     FHS compliant because there is only currently a single pid file, but
>     this gives us greater future flexibility and is in the spirit of FHS.
> 
>     CONFIG_DIR is used to hold the site configuration files. FHS wants
>     configuration files stored in /etc/mailman. Previously configuration
>     files were mixed in with data files in DATA_DIR and with the run-time
>     code (e.g. Mailman/mm_cfg.py). CONFIG_DIR continues to exist but is
>     now restricted to data files (e.g. python pickle files). The password
>     files, alias files, and .cfg (e.g. sitelist.cfg) files have been moved
>     to CONFIG_DIR. mm_cfg.py which is the primary mailman configuration
>     file was presented a bit of a dilemma. In theory it should be located
>     in /etc/mailman, however it is executable code which argues it should
>     be located with the other executable files, it has traditionally lived
>     in $PREFIX/Mailman and experienced mailman admins will expect to find
>     it there. Modifying all the mm_cfg import statements and paths.py was
>     believed to be too invasive a change, and technically its part of the
>     "Mailman" package and moving it would take it out of the package
>     (although currently I don't think that presents any known
>     issues). Instead a compromise approach was adopted, mm_cfg.py is
>     symbolically linked into the /etc/mailman directory pointing to
>     $PREFIX/Mailman/mm_cfg.py. Thus mm_cfg.py "appears" in the
>     configuration directory but retains its traditional location, this was
>     deemed a reasonable compromise for the mailman 2.1.x timeframe.
> 
>     sitelist.cfg has a symbolic link in its old location in the DATA_DIR
>     pointing to its new location in the CONFIG_DIR.
> 
>     New Directories (can be specified as parameter to configure):
> 
>     CONFIG_DIR:	default=$VAR_PREFIX/data		FHS=/etc/mailman
>     PID_DIR	default=$VAR_PREFIX/data		FHS=/var/run/mailman
> 
>     Existing directories that can now be specified as parameter to configure:
> 
>     LOCK_DIR:	default=$VAR_PREFIX/locks	FHS=/var/lock/mailman
>     LOG_DIR:	default=$VAR_PREFIX/logs	FHS=/var/log/mailman
>     QUEUE_DIR	default=$VAR_PREFIX/qfiles	FHS=/var/spool/mailman
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> Only in mailman-2.1.5.FHS: autom4te.cache
> diff -r -u mailman-2.1.5.orig/bin/check_perms mailman-2.1.5.FHS/bin/check_perms
> --- mailman-2.1.5.orig/bin/check_perms	2003-03-31 15:07:55.000000000 -0500
> +++ mailman-2.1.5.FHS/bin/check_perms	2004-10-08 16:05:09.000000000 -0400
> @@ -164,7 +164,8 @@
>          print _('checking mode for %(prefix)s')
>      dirs = {}
>      for d in (mm_cfg.PREFIX, mm_cfg.EXEC_PREFIX, mm_cfg.VAR_PREFIX,
> -              mm_cfg.LOG_DIR):
> +              mm_cfg.CONFIG_DIR, mm_cfg.DATA_DIR, mm_cfg.LOCK_DIR,
> +              mm_cfg.LOG_DIR, mm_cfg.QUEUE_DIR, mm_cfg.PID_DIR):
>          dirs[d] = True
>      for d in dirs.keys():
>          try:
> Only in mailman-2.1.5.FHS/bin: check_perms~
> Only in mailman-2.1.5.FHS: config.log
> Only in mailman-2.1.5.FHS: configure
> diff -r -u mailman-2.1.5.orig/configure.in mailman-2.1.5.FHS/configure.in
> --- mailman-2.1.5.orig/configure.in	2003-12-24 12:11:48.000000000 -0500
> +++ mailman-2.1.5.FHS/configure.in	2004-09-30 16:13:56.000000000 -0400
> @@ -180,7 +180,7 @@
>  AC_SUBST(VAR_PREFIX)
>  AC_MSG_CHECKING(for --with-var-prefix)
>  AC_ARG_WITH(var-prefix, dnl
> -[  --with-var-prefix     directory for mutable data [/var/mailman]])
> +[  --with-var-prefix    directory for mutable data [/var/mailman]])
>  case "$with_var_prefix" in
>          yes)    VAR_PREFIX="$default_var_prefix"; ans=$VAR_PREFIX;;
>          ""|no)  VAR_PREFIX="$prefix"; ans="no";;
> @@ -207,6 +207,61 @@
>      prefixcheck=$VAR_PREFIX
>  fi
>  
> +# Get the configuration file directory
> +AC_SUBST(CONFIG_DIR)
> +AC_MSG_CHECKING(for --with-config-dir)
> +AC_ARG_WITH(config-dir, dnl
> +[  --with-config-dir    specify directory for configuration data other than [VAR_]PREFIX/data])
> +case "$with_config_dir" in
> +    yes|no|"") CONFIG_DIR="$VAR_PREFIX/data";;
> +    *)         CONFIG_DIR=$with_config_dir;;
> +esac
> +AC_MSG_RESULT($CONFIG_DIR)
> +
> +# Get the lock directory
> +AC_SUBST(LOCK_DIR)
> +AC_MSG_CHECKING(for --with-lock-dir)
> +AC_ARG_WITH(lock-dir, dnl
> +[  --with-lock-dir    specify directory for lock files other than [VAR_]PREFIX/locks])
> +case "$with_lock_dir" in
> +    yes|no|"") LOCK_DIR="$VAR_PREFIX/locks";;
> +    *)         LOCK_DIR=$with_lock_dir;;
> +esac
> +AC_MSG_RESULT($LOCK_DIR)
> +
> +# Get the log directory
> +AC_SUBST(LOG_DIR)
> +AC_MSG_CHECKING(for --with-log-dir)
> +AC_ARG_WITH(log-dir, dnl
> +[  --with-log-dir    specify directory for log files other than [VAR_]PREFIX/logs])
> +case "$with_log_dir" in
> +    yes|no|"") LOG_DIR="$VAR_PREFIX/logs";;
> +    *)         LOG_DIR=$with_log_dir;;
> +esac
> +AC_MSG_RESULT($LOG_DIR)
> +
> +# Get the pid directory
> +AC_SUBST(PID_DIR)
> +AC_MSG_CHECKING(for --with-pid-dir)
> +AC_ARG_WITH(pid-dir, dnl
> +[  --with-pid-dir    specify directory for the pid file other than [VAR_]PREFIX/data])
> +case "$with_pid_dir" in
> +    yes|no|"") PID_DIR="$VAR_PREFIX/data";;
> +    *)         PID_DIR=$with_pid_dir;;
> +esac
> +AC_MSG_RESULT($PID_DIR)
> +
> +# Get the queue directory
> +AC_SUBST(QUEUE_DIR)
> +AC_MSG_CHECKING(for --with-queue-dir)
> +AC_ARG_WITH(queue-dir, dnl
> +[  --with-queue-dir    specify directory for queue files other than [VAR_]PREFIX/qfiles])
> +case "$with_queue_dir" in
> +    yes|no|"") QUEUE_DIR="$VAR_PREFIX/qfiles";;
> +    *)         QUEUE_DIR=$with_queue_dir;;
> +esac
> +AC_MSG_RESULT($QUEUE_DIR)
> +
>  # new macro for finding group names
>  AC_DEFUN(MM_FIND_GROUP_NAME, [
>  # $1 == variable name
> @@ -619,7 +674,7 @@
>             templates/Makefile cron/Makefile scripts/Makefile messages/Makefile
>             cron/crontab.in misc/mailman Makefile
>             tests/Makefile tests/bounces/Makefile tests/msgs/Makefile
> -           $SCRIPTS],
> +           $SCRIPTS ],
>          echo "configuration completed at" `date`)
>  
>  # Make sure all the build scripts are executable.
> Only in mailman-2.1.5.FHS: configure.in~
> diff -r -u mailman-2.1.5.orig/Mailman/Defaults.py.in mailman-2.1.5.FHS/Mailman/Defaults.py.in
> --- mailman-2.1.5.orig/Mailman/Defaults.py.in	2004-04-24 22:30:03.000000000 -0400
> +++ mailman-2.1.5.FHS/Mailman/Defaults.py.in	2004-10-08 14:38:57.000000000 -0400
> @@ -1198,9 +1198,11 @@
>  
>  # Useful directories
>  LIST_DATA_DIR   = os.path.join(VAR_PREFIX, 'lists')
> -LOG_DIR         = os.path.join(VAR_PREFIX, 'logs')
> -LOCK_DIR        = os.path.join(VAR_PREFIX, 'locks')
> +LOG_DIR         = '@LOG_DIR@'
> +LOCK_DIR        = '@LOCK_DIR@'
> +CONFIG_DIR      = '@CONFIG_DIR@'
>  DATA_DIR        = os.path.join(VAR_PREFIX, 'data')
> +PID_DIR         = '@PID_DIR@'
>  SPAM_DIR        = os.path.join(VAR_PREFIX, 'spam')
>  WRAPPER_DIR     = os.path.join(EXEC_PREFIX, 'mail')
>  BIN_DIR         = os.path.join(PREFIX, 'bin')
> @@ -1211,7 +1213,7 @@
>  PRIVATE_ARCHIVE_FILE_DIR = os.path.join(VAR_PREFIX, 'archives', 'private')
>  
>  # Directories used by the qrunner subsystem
> -QUEUE_DIR       = os.path.join(VAR_PREFIX, 'qfiles')
> +QUEUE_DIR       = '@QUEUE_DIR@'
>  INQUEUE_DIR     = os.path.join(QUEUE_DIR, 'in')
>  OUTQUEUE_DIR    = os.path.join(QUEUE_DIR, 'out')
>  CMDQUEUE_DIR    = os.path.join(QUEUE_DIR, 'commands')
> @@ -1225,9 +1227,9 @@
>  MAILDIR_DIR     = os.path.join(QUEUE_DIR, 'maildir')
>  
>  # Other useful files
> -PIDFILE = os.path.join(DATA_DIR, 'master-qrunner.pid')
> -SITE_PW_FILE = os.path.join(DATA_DIR, 'adm.pw')
> -LISTCREATOR_PW_FILE = os.path.join(DATA_DIR, 'creator.pw')
> +PIDFILE = os.path.join(PID_DIR, 'master-qrunner.pid')
> +SITE_PW_FILE = os.path.join(CONFIG_DIR, 'adm.pw')
> +LISTCREATOR_PW_FILE = os.path.join(CONFIG_DIR, 'creator.pw')
>  
>  # Import a bunch of version numbers
>  from Version import *
> Only in mailman-2.1.5.FHS/Mailman: Defaults.py.in~
> diff -r -u mailman-2.1.5.orig/Mailman/MTA/Postfix.py mailman-2.1.5.FHS/Mailman/MTA/Postfix.py
> --- mailman-2.1.5.orig/Mailman/MTA/Postfix.py	2003-03-31 16:49:43.000000000 -0500
> +++ mailman-2.1.5.FHS/Mailman/MTA/Postfix.py	2004-10-08 16:02:20.000000000 -0400
> @@ -32,8 +32,8 @@
>  from Mailman.Logging.Syslog import syslog
>  
>  LOCKFILE = os.path.join(mm_cfg.LOCK_DIR, 'creator')
> -ALIASFILE = os.path.join(mm_cfg.DATA_DIR, 'aliases')
> -VIRTFILE = os.path.join(mm_cfg.DATA_DIR, 'virtual-mailman')
> +ALIASFILE = os.path.join(mm_cfg.CONFIG_DIR, 'aliases')
> +VIRTFILE = os.path.join(mm_cfg.CONFIG_DIR, 'virtual-mailman')
>  
>  try:
>      True, False
> Only in mailman-2.1.5.FHS/Mailman/MTA: Postfix.py~
> Only in mailman-2.1.5.orig: mailman-FHS.patch
> diff -r -u mailman-2.1.5.orig/Makefile.in mailman-2.1.5.FHS/Makefile.in
> --- mailman-2.1.5.orig/Makefile.in	2003-03-31 14:26:57.000000000 -0500
> +++ mailman-2.1.5.FHS/Makefile.in	2004-10-15 16:48:17.000000000 -0400
> @@ -28,6 +28,11 @@
>  prefix=		@prefix@
>  exec_prefix=	@exec_prefix@
>  var_prefix=	@VAR_PREFIX@
> +configdir=	@CONFIG_DIR@
> +lockdir=	@LOCK_DIR@
> +logdir=		@LOG_DIR@
> +piddir=		@PID_DIR@
> +queuedir=	@QUEUE_DIR@
>  DESTDIR=
>  
>  CC=		@CC@
> @@ -41,8 +46,12 @@
>  OPT=		@OPT@
>  CFLAGS=		@CFLAGS@ $(OPT) $(DEFS)
>  
> +FHS_DIRS= \
> +	${configdir} ${lockdir} ${logdir} ${piddir} ${queuedir}
> +
> +
>  VAR_DIRS= \
> -	logs archives lists locks data spam qfiles \
> +	archives lists data spam \
>  	archives/private archives/public
>  
>  ARCH_INDEP_DIRS= \
> @@ -96,6 +105,15 @@
>  	    else true; \
>  	    fi; \
>  	done
> +	@for d in $(FHS_DIRS); \
> +	do \
> +	    dir=$(DESTDIR)/$$d; \
> +	    if test ! -d $$dir; then \
> +		echo "Creating directory $$dir"; \
> +		$(INSTALL) -d -m $(DIRMODE) $$dir; \
> +	    else true; \
> +	    fi; \
> +	done
>  	chmod o-r $(DESTDIR)$(var_prefix)/archives/private
>  	@for d in $(ARCH_INDEP_DIRS); \
>  	do \
> Only in mailman-2.1.5.FHS: Makefile.in~
> Only in mailman-2.1.5.FHS/messages: Makefile.in~
> diff -r -u mailman-2.1.5.orig/misc/mailman.in mailman-2.1.5.FHS/misc/mailman.in
> --- mailman-2.1.5.orig/misc/mailman.in	2003-09-25 18:13:26.000000000 -0400
> +++ mailman-2.1.5.FHS/misc/mailman.in	2004-10-06 16:15:28.000000000 -0400
> @@ -24,13 +24,13 @@
>  # On Debian, type "update-rc.d mailman defaults"
>  # On RedHat, and derivatives, install with "chkconfig --add mailman"
>  #
> -# chkconfig: 2345 98 12
> +# chkconfig: - 98 12
>  # description: Mailman is the GNU Mailing List Manager, a program that \
>  #              manages electronic mail discussion groups.  For more \
>  #              on GNU Mailman see http://www.list.org
>  # processname: mailmanctl
>  # config: @prefix@/Mailman/mm_cfg.py
> -# pidfile: @prefix@/data/master-qrunner.pid
> +# pidfile: @PID_DIR@/master-qrunner.pid
>  
>  PYTHON=@PYTHON@
>  MAILMANHOME=@prefix@
> Only in mailman-2.1.5.FHS/misc: mailman.in~
> diff -r -u mailman-2.1.5.orig/misc/Makefile.in mailman-2.1.5.FHS/misc/Makefile.in
> --- mailman-2.1.5.orig/misc/Makefile.in	2004-05-13 23:34:34.000000000 -0400
> +++ mailman-2.1.5.FHS/misc/Makefile.in	2004-10-13 14:00:19.000000000 -0400
> @@ -26,6 +26,12 @@
>  prefix=   	@prefix@
>  exec_prefix=	@exec_prefix@
>  var_prefix=	@VAR_PREFIX@
> +configdir=	@CONFIG_DIR@
> +lockdir=	@LOCK_DIR@
> +logdir=		@LOG_DIR@
> +piddir=		@PID_DIR@
> +queuedir=	@QUEUE_DIR@
> +MAILMAN_GROUP=  @MAILMAN_GROUP@
>  DESTDIR=
>  
>  CC=		@CC@
> @@ -84,7 +90,7 @@
>  	    $(INSTALL) -m $(FILEMODE) paths.py $$dir; \
>  	done
>  	$(INSTALL) -m $(EXEMODE) mailman $(DESTDIR)$(SCRIPTSDIR)
> -	$(INSTALL) -m $(FILEMODE) sitelist.cfg $(DESTDIR)$(DATADIR)
> +	$(INSTALL) -m $(FILEMODE) sitelist.cfg $(DESTDIR)$(configdir)
>  
>  install-packages:
>  	for p in $(PACKAGES); \
> Only in mailman-2.1.5.FHS/misc: Makefile.in~
> Only in mailman-2.1.5.FHS/templates: Makefile.in~
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com
From Dale at Newfield.org  Tue Oct 19 07:36:09 2004
From: Dale at Newfield.org (Dale Newfield)
Date: Tue Oct 19 07:36:13 2004
Subject: [Mailman-Developers] FHS installation changes
In-Reply-To: <41749604.7030409@nleaudio.com>
References: <1098131181.9340.103.camel@finch.boston.redhat.com>
	<41749604.7030409@nleaudio.com>
Message-ID: <Pine.OSX.4.58.0410190127070.28144@bambi-newfield-org.local>

On Tue, 19 Oct 2004, Bob Puff@NLE wrote:
> John makes some really valid points here.  While it is a bit more of a
> change, FHS compatibility does make sense.  Is this something that we
> can consider for future 2.1.x releases?

Upgradability without problems is very important for patch-level releases.
I like the ability to specify more "put this there" detail in the
configuration options, but I'd be leery of doing this upgrade in 2.1
without very careful documentation of ALL the suggested changes (forwards
and backwards), and enough testing to confidently be able to say that an
admin that *doesn't* want to change the location of anything can just run
"mailmanctl stop;config.status;make install;mailmanctl start" and still
have everything work.

-Dale
From thebestofkolkata at yahoo.com  Tue Oct 19 08:09:31 2004
From: thebestofkolkata at yahoo.com (Suman Halder)
Date: Tue Oct 19 08:09:33 2004
Subject: [Mailman-Developers] Pls Help regarding user's real name
	(Personalisation of emails)
Message-ID: <20041019060931.28587.qmail@web53501.mail.yahoo.com>

Dear all,
 
Please tell me how i can include mailing list users real name with their emails. (i.e. "someone" abc@xyz.com) and i also want to include their real names in the footers of respective mails.
I know most of u know how to do it. So pls help me. I am using Mailman 2.1.5
 
Thanx,
Suman Halder
 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
From jwt at OnJapan.net  Tue Oct 19 10:18:38 2004
From: jwt at OnJapan.net (Jim Tittsler)
Date: Tue Oct 19 10:17:23 2004
Subject: [Mailman-Developers] Pls Help regarding user's real name
	(Personalisation of emails)
In-Reply-To: <20041019060931.28587.qmail@web53501.mail.yahoo.com>
References: <20041019060931.28587.qmail@web53501.mail.yahoo.com>
Message-ID: <20041019081837.GA3155@server.onjapan.net>

On Mon, Oct 18, 2004 at 11:09:31PM -0700, Suman Halder wrote:
> Please tell me how i can include mailing list users real name
> with their emails. (i.e. "someone" abc@xyz.com) and i also
> want to include their real names in the footers of respective
> mails. I know most of u know how to do it. So pls help me. I
> am using Mailman 2.1.5

Check the help section for the 'personalize' setting on the
'Non-digest options' page of the list's administrative
interface.  If you set 'personalize' to Yes (or Full) you can
use %(user_name)s to include the subscriber's name in the
header or footer.

(Note that your system administrator will have had to enable
personalization by setting
 OWNERS_CAN_ENABLE_PERSONALIZATION = Yes
in their mm_cfg.py file.)

-- 
Jim Tittsler             http://www.OnJapan.net/      GPG: 0x01159DB6
Python Starship          http://Starship.Python.net/
Ringo MUG Tokyo          http://www.ringo.net/rss.html

From jdennis at redhat.com  Tue Oct 19 17:21:10 2004
From: jdennis at redhat.com (John Dennis)
Date: Tue Oct 19 17:21:14 2004
Subject: [Mailman-Developers] FHS installation changes
In-Reply-To: <Pine.OSX.4.58.0410190127070.28144@bambi-newfield-org.local>
References: <1098131181.9340.103.camel@finch.boston.redhat.com>
	<41749604.7030409@nleaudio.com>
	<Pine.OSX.4.58.0410190127070.28144@bambi-newfield-org.local>
Message-ID: <1098199270.9340.177.camel@finch.boston.redhat.com>

On Tue, 2004-10-19 at 01:36, Dale Newfield wrote:
> On Tue, 19 Oct 2004, Bob Puff@NLE wrote:
> > John makes some really valid points here.  While it is a bit more of a
> > change, FHS compatibility does make sense.  Is this something that we
> > can consider for future 2.1.x releases?
> 
> Upgradability without problems is very important for patch-level releases.
> I like the ability to specify more "put this there" detail in the
> configuration options, but I'd be leery of doing this upgrade in 2.1
> without very careful documentation of ALL the suggested changes (forwards
> and backwards), and enough testing to confidently be able to say that an
> admin that *doesn't* want to change the location of anything can just run
> "mailmanctl stop;config.status;make install;mailmanctl start" and still
> have everything work.

In theory if the patch is applied to 2.1.5 nothing should change, it
should produce the exact same installation as previously.

O.K. thats theory, and then there is actual practice :-) Which is why
I'm 100% in Dale's camp of wanting testing. One of my concerns is being
blinded by my own computing environment or my own assumptions.

One potential for problems is that packaging introduces an entire extra
set of operations beyond mailman's "make install" step. Things which
occur during package creation and package installation augment what
occurs in "make install" and as consequence may mask problems or
introduce problems, none of which would exist when building from a
vanilla tarball. This is a significant consideration.

We've also made some enhancements to mailmanctl to better integrate with
init.d scripts and system service control. It's not clear to me if this
is generally applicable but I'm more than happy to share. One
enhancement I think is general case is the ability to invoke mailmanctl
and have it return process status (e.g. is the master qrunner running,
if so what is its pid, the pid file is not sufficient to answer this
question and there were permission issues to overcome), this allows a
non-root, non-mailman user to do "/sbin/service mailman status"
-- 
John Dennis <jdennis@redhat.com>

From Dale at Newfield.org  Tue Oct 19 17:34:24 2004
From: Dale at Newfield.org (Dale Newfield)
Date: Tue Oct 19 17:34:28 2004
Subject: [Mailman-Developers] FHS installation changes
In-Reply-To: <1098199270.9340.177.camel@finch.boston.redhat.com>
References: <1098131181.9340.103.camel@finch.boston.redhat.com>
	<41749604.7030409@nleaudio.com>
	<Pine.OSX.4.58.0410190127070.28144@bambi-newfield-org.local>
	<1098199270.9340.177.camel@finch.boston.redhat.com>
Message-ID: <Pine.OSX.4.58.0410191132000.6021@bambi-newfield-org.local>

On Tue, 19 Oct 2004, John Dennis wrote:
> > "mailmanctl stop;config.status;make install;mailmanctl start"

Just remembered that I missed "check_perms -f" in there.  Which of course
brings up the point that presumably this script would need lots of
(configuration dependent) changes made to it as well.  Did you catch that
one?

-Dale
From jdennis at redhat.com  Tue Oct 19 17:54:10 2004
From: jdennis at redhat.com (John Dennis)
Date: Tue Oct 19 17:54:15 2004
Subject: [Mailman-Developers] FHS installation changes
In-Reply-To: <Pine.OSX.4.58.0410191132000.6021@bambi-newfield-org.local>
References: <1098131181.9340.103.camel@finch.boston.redhat.com>
	<41749604.7030409@nleaudio.com>
	<Pine.OSX.4.58.0410190127070.28144@bambi-newfield-org.local>
	<1098199270.9340.177.camel@finch.boston.redhat.com>
	<Pine.OSX.4.58.0410191132000.6021@bambi-newfield-org.local>
Message-ID: <1098201250.9340.198.camel@finch.boston.redhat.com>

On Tue, 2004-10-19 at 11:34, Dale Newfield wrote:
> On Tue, 19 Oct 2004, John Dennis wrote:
> > > "mailmanctl stop;config.status;make install;mailmanctl start"
> 
> Just remembered that I missed "check_perms -f" in there.  Which of course
> brings up the point that presumably this script would need lots of
> (configuration dependent) changes made to it as well.  Did you catch that
> one?

I did take that into consideration and I don't believe I introduced any
problems. The fundamental logic of the script was unaltered, the primary
change was the addition of new directories to scan to the existing
directory list. This means the function checkwalk, which is where all
the action happens is now invoked on a few more directories. If the old
directory structure is being used then checkwalk has the potential to
descend into a directory more than once, however there was already logic
in checkwalk to prevent redundant scanning.

There are a couple of special directories which are not processed by the
generic checkwalk and instead are handled by custom functions, however
these were unaffected.

However I must caution that my testing of "check_perm -f" was limited
since there were no problems to fix. I suppose I could have manually
altered files and tried "check_perm -f" but I'll confess I didn't go to
that level of testing nor did I test on a non FHS installation.

Bottom line: I don't think there are problems but testing is incomplete.

-- 
John Dennis <jdennis@redhat.com>

From tim at timmorgan.org  Tue Oct 19 20:04:01 2004
From: tim at timmorgan.org (Tim Morgan)
Date: Tue Oct 19 20:19:51 2004
Subject: [Mailman-Developers] Member Adaptor Half Working
Message-ID: <5405.65.69.107.245.1098209041.squirrel@65.69.107.245>

I have managed to create my own MySQL-based member adaptor and have
integrated it into one of my mailing lists using the extend.py mechanism.
I was very pleased when it worked with very little debugging, however I
found later it is only half working.

When I go to the administrative interface of the list, I can see the
members from the MySQL database in the membership list. However, when
email is sent to the list from one of the member addresses, it is held for
approval due to "post by non-member to member-only list". When approved,
the message is added to the archive, but no one in the membership receives
it. It's as if Mailman is using my Member Adaptor for some tasks, but
using the old method of member storage for the important stuff, e.g.
accepting and distributing messages.

Any ideas?
From claw at kanga.nu  Wed Oct 20 01:51:17 2004
From: claw at kanga.nu (J C Lawrence)
Date: Wed Oct 20 01:51:28 2004
Subject: [Mailman-Developers] Can we remove nimda.txt ?
In-Reply-To: Message from Barry Warsaw <barry@python.org> of "Sun,
	17 Oct 2004 21:07:30 EDT." <1098061650.18272.26.camel@geddy.wooz.org>
References: <4170B701.7060103@is.kochi-u.ac.jp>
	<p0600200bbd966d04ed83@[24.165.137.33]>
	<1098061650.18272.26.camel@geddy.wooz.org>
Message-ID: <7227.1098229877@kanga.nu>

On Sun, 17 Oct 2004 21:07:30 -0400
Barry Warsaw <barry@python.org> wrote:

> /Should/ we require VERP?  My preference would be "no".

Seconded.

--
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
claw@kanga.nu               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.
From grnbrg at gmail.com  Thu Oct 21 19:59:15 2004
From: grnbrg at gmail.com (Brian Greenberg)
Date: Thu Oct 21 19:59:21 2004
Subject: [Mailman-Developers] Multi-slice qrunners to be fixed for 2.1.6?
	(Re: SF Patch 1008983)
Message-ID: <2f30f3450410211059248907b2@mail.gmail.com>

Just wondering if this patch
(http://sourceforge.net/tracker/index.php?func=detail&aid=1008983&group_id=103&atid=300103)
has been noticed.  It should have a fairly high priority, as it will
result in any qrunner class with multiple slices failing completely in
a short amount of time (hours to a few days, depending on the amount
of traffic and number of slices).

The fix is trivial, merely clarifying an if statement, so it should
have minimal impact on other areas.


Brian.
ObOtherPatchPlug:  Patch 1045656 reduces logfile chatter resulting
from a lockfile race that does not impact operation.
-- 
Brian Greenberg
grnbrg@gmail.com
From tkikuchi at is.kochi-u.ac.jp  Fri Oct 22 01:37:52 2004
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Fri Oct 22 01:38:13 2004
Subject: [Mailman-Developers] Multi-slice qrunners to be fixed for 2.1.6?
	(Re: SF Patch 1008983)
In-Reply-To: <2f30f3450410211059248907b2@mail.gmail.com>
References: <2f30f3450410211059248907b2@mail.gmail.com>
Message-ID: <41784850.2070505@is.kochi-u.ac.jp>

Brian Greenberg wrote:

> Just wondering if this patch
> (http://sourceforge.net/tracker/index.php?func=detail&aid=1008983&group_id=103&atid=300103)
> has been noticed.  

Yes, I know it is there.

> It should have a fairly high priority, as it will
> result in any qrunner class with multiple slices failing completely in
> a short amount of time (hours to a few days, depending on the amount
> of traffic and number of slices).

I really don't understand why the multiple feature is needed for mail
delivery as multi-threading may be handled by MTA. It was left there
because I am not in a position to test or qualify your patch
immediately. If there is anyone who can backup this patch, I will be
ready to merge in CVS.

> 
> The fix is trivial, merely clarifying an if statement, so it should
> have minimal impact on other areas.

I would like to ask patience here again as there were many FAQ related 
bug fixes in the past month. I always browse through patch/bug trackers 
whenever I have time.

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

From dallas at dreamhost.com  Fri Oct 22 01:54:05 2004
From: dallas at dreamhost.com (Dallas Bethune)
Date: Fri Oct 22 01:54:11 2004
Subject: [Mailman-Developers] Multi-slice qrunners to be fixed for 2.1.6?
	(Re: SF Patch 1008983)
In-Reply-To: <41784850.2070505@is.kochi-u.ac.jp>
References: <2f30f3450410211059248907b2@mail.gmail.com>
	<41784850.2070505@is.kochi-u.ac.jp>
Message-ID: <7D8C4052-23BC-11D9-9501-000A95AA76E0@dreamhost.com>


On Oct 21, 2004, at 4:37 PM, Tokio Kikuchi wrote:

> Brian Greenberg wrote:
>
>> It should have a fairly high priority, as it will
>> result in any qrunner class with multiple slices failing completely in
>> a short amount of time (hours to a few days, depending on the amount
>> of traffic and number of slices).
>
> I really don't understand why the multiple feature is needed for mail
> delivery as multi-threading may be handled by MTA. It was left there
> because I am not in a position to test or qualify your patch
> immediately. If there is anyone who can backup this patch, I will be
> ready to merge in CVS.

The MTA cannot perform multithreading between multiple lists.  For 
instance, if there is one list with 10,000 subscribers no other 
deliveries can be made while the emails to those 10,000 people are 
being transferred to the MTA.  In some cases that may delay all other 
list delivery by several minutes and if that happens many times a day 
it can become problematic to end users.  Having multiple outgoing 
qrunners allows other list mail to be delivered simultaneously.

I have also seen the bug this patch addresses happen.  I saw one of the 
outgoing qrunner processes die within about 15 minutes of restarting 
mailman to have 4 of them.  They continued to die (and be restarted by 
the master) for the next several hours.  Once I applied the patch, the 
errors stopped.

I have not done any sort of extensive testing, but it has been working 
as expected for the past 3 days with the 3000 or so lists we have 
running on the machine.

	Dallas

From tkikuchi at is.kochi-u.ac.jp  Fri Oct 22 02:19:29 2004
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Fri Oct 22 02:19:50 2004
Subject: [Mailman-Developers] Multi-slice qrunners to be fixed for 2.1.6?
	(Re: SF Patch 1008983)
In-Reply-To: <7D8C4052-23BC-11D9-9501-000A95AA76E0@dreamhost.com>
References: <2f30f3450410211059248907b2@mail.gmail.com>	<41784850.2070505@is.kochi-u.ac.jp>
	<7D8C4052-23BC-11D9-9501-000A95AA76E0@dreamhost.com>
Message-ID: <41785211.3020207@is.kochi-u.ac.jp>

So, you back up. That's I wanted to hear.

Dallas Bethune wrote:

> 
> On Oct 21, 2004, at 4:37 PM, Tokio Kikuchi wrote:
> 
>> Brian Greenberg wrote:
>>
>>> It should have a fairly high priority, as it will
>>> result in any qrunner class with multiple slices failing completely in
>>> a short amount of time (hours to a few days, depending on the amount
>>> of traffic and number of slices).
>>
>>
>> I really don't understand why the multiple feature is needed for mail
>> delivery as multi-threading may be handled by MTA. It was left there
>> because I am not in a position to test or qualify your patch
>> immediately. If there is anyone who can backup this patch, I will be
>> ready to merge in CVS.
> 
> 
> The MTA cannot perform multithreading between multiple lists.  For 
> instance, if there is one list with 10,000 subscribers no other 
> deliveries can be made while the emails to those 10,000 people are being 
> transferred to the MTA.  In some cases that may delay all other list 
> delivery by several minutes and if that happens many times a day it can 
> become problematic to end users.  Having multiple outgoing qrunners 
> allows other list mail to be delivered simultaneously.
> 
> I have also seen the bug this patch addresses happen.  I saw one of the 
> outgoing qrunner processes die within about 15 minutes of restarting 
> mailman to have 4 of them.  They continued to die (and be restarted by 
> the master) for the next several hours.  Once I applied the patch, the 
> errors stopped.
> 
> I have not done any sort of extensive testing, but it has been working 
> as expected for the past 3 days with the 3000 or so lists we have 
> running on the machine.
> 
>     Dallas
> 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Unsubscribe: 
> http://mail.python.org/mailman/options/mailman-developers/tkikuchi%40is.kochi-u.ac.jp 
> 
> 
> 
> 

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

From brad at stop.mail-abuse.org  Fri Oct 22 03:00:34 2004
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Fri Oct 22 03:01:03 2004
Subject: [Mailman-Developers] Multi-slice qrunners to be fixed
	for 2.1.6? 	(Re: SF Patch 1008983)
In-Reply-To: <7D8C4052-23BC-11D9-9501-000A95AA76E0@dreamhost.com>
References: <2f30f3450410211059248907b2@mail.gmail.com>
	<41784850.2070505@is.kochi-u.ac.jp>
	<7D8C4052-23BC-11D9-9501-000A95AA76E0@dreamhost.com>
Message-ID: <p06002028bd9e0bb081d9@[10.0.1.3]>

At 4:54 PM -0700 2004-10-21, Dallas Bethune wrote:

>  The MTA cannot perform multithreading between multiple lists.

	More accurately, the MTA is limited in its ability to apply 
multi-threaded solutions to problems when the input bottleneck from 
the qrunner is single-threaded.

>                                                                 For
>  instance, if there is one list with 10,000 subscribers no other
>  deliveries can be made while the emails to those 10,000 people are
>  being transferred to the MTA.  In some cases that may delay all other
>  list delivery by several minutes and if that happens many times a day
>  it can become problematic to end users.  Having multiple outgoing
>  qrunners allows other list mail to be delivered simultaneously.

	Some of these problems can be addressed through improvements to 
MTA configuration, but it certainly sounds like the ability to have 
multiple qrunners going at the same time would allow the MTA a better 
chance to maximize the potential overall mailing list throughput that 
the server is capable of.

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

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

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

   SAGE member since 1995.  See <http://www.sage.org/> for more info.
From barry at python.org  Fri Oct 22 03:54:13 2004
From: barry at python.org (Barry Warsaw)
Date: Fri Oct 22 03:54:22 2004
Subject: [Mailman-Developers] Multi-slice qrunners to be fixed for
	2.1.6? (Re: SF Patch 1008983)
In-Reply-To: <2f30f3450410211059248907b2@mail.gmail.com>
References: <2f30f3450410211059248907b2@mail.gmail.com>
Message-ID: <1098410053.7750.1.camel@geddy.wooz.org>

On Thu, 2004-10-21 at 13:59, Brian Greenberg wrote:

> The fix is trivial, merely clarifying an if statement, so it should
> have minimal impact on other areas.

As I mentioned in the tracker comment, I think a better patch is to
change the "if not lower" to "if lower is None".

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20041021/fd8fc038/attachment.pgp
From barry at python.org  Fri Oct 22 03:58:03 2004
From: barry at python.org (Barry Warsaw)
Date: Fri Oct 22 03:58:06 2004
Subject: [Mailman-Developers] Multi-slice qrunners to be fixed for
	2.1.6? (Re: SF Patch 1008983)
In-Reply-To: <7D8C4052-23BC-11D9-9501-000A95AA76E0@dreamhost.com>
References: <2f30f3450410211059248907b2@mail.gmail.com>
	<41784850.2070505@is.kochi-u.ac.jp>
	<7D8C4052-23BC-11D9-9501-000A95AA76E0@dreamhost.com>
Message-ID: <1098410283.7750.5.camel@geddy.wooz.org>

On Thu, 2004-10-21 at 19:54, Dallas Bethune wrote:

> The MTA cannot perform multithreading between multiple lists.  For 
> instance, if there is one list with 10,000 subscribers no other 
> deliveries can be made while the emails to those 10,000 people are 
> being transferred to the MTA.  In some cases that may delay all other 
> list delivery by several minutes and if that happens many times a day 
> it can become problematic to end users.  Having multiple outgoing 
> qrunners allows other list mail to be delivered simultaneously.

Note that the OutgoingRunner was designed to never (or almost never)
need the list lock, so it should not block other access to the MailList
while it's doing its job.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20041021/5bc56b4d/attachment.pgp
From tneff at grassyhill.org  Fri Oct 22 14:50:23 2004
From: tneff at grassyhill.org (Tom Neff)
Date: Fri Oct 22 14:50:28 2004
Subject: [Mailman-Developers] We may need to escape percent signs in admin
	forms
In-Reply-To: <20041022100117.A1C101E4020@bag.python.org>
References: <20041022100117.A1C101E4020@bag.python.org>
Message-ID: <ED418EAA8F531A4AA5C8E488@[192.168.0.18]>

I notice that on one of my lists, a moderator had been using the "Add 
(address) to a sender filter" checkbox on a lot of pending moderator 
requests, so that a substantial list of automatic-discard addresses had 
been built *without* ever using the Sender Filters admin page.

When I went to the Sender Filters page myself and tried to change something 
else, the Submit blew up with

	TypeError: not enough arguments for format string

in htmlformat.py .  I googled this and on a couple of Python forums I found 
the suggestion than an un-escaped percent sign had found its way into a 
template.  My templates are untouched but Mailman builds a lot of documents 
on the fly, so I scanned the pre-submit Sender Filters page source for 
percents and lo, there were a couple in the list of auto-discard email 
addresses.  On a whim I removed them and re-Submitted.  Instant success.

I am too swamped to hack the Mailman code right now but if someone wants to 
take a look, it may be that there is something called addError that is 
passing un-escaped text.  We might want to come in after any template 
substitution and escape what's left.  Or something.
From dgc at uchicago.edu  Fri Oct 22 19:57:59 2004
From: dgc at uchicago.edu (David Champion)
Date: Fri Oct 22 19:58:38 2004
Subject: [Mailman-Developers] Re: Multi-slice qrunners to be fixed for
	2.1.6? (Re: SF Patch 1008983)
In-Reply-To: <p06002028bd9e0bb081d9@[10.0.1.3]>
References: <2f30f3450410211059248907b2@mail.gmail.com>
	<41784850.2070505@is.kochi-u.ac.jp>
	<7D8C4052-23BC-11D9-9501-000A95AA76E0@dreamhost.com>
	<p06002028bd9e0bb081d9@[10.0.1.3]>
Message-ID: <20041022175759.GC15641@monkey.uchicago.edu>

* On 2004.10.21, in <p06002028bd9e0bb081d9@[10.0.1.3]>,
*	"Brad Knowles" <brad@stop.mail-abuse.org> wrote:
> 
> MTA configuration, but it certainly sounds like the ability to have 
> multiple qrunners going at the same time would allow the MTA a better 
> chance to maximize the potential overall mailing list throughput that 
> the server is capable of.

Yes, yes, yes. I'll back up the problem here: we see this kind of
situation regularly, even moreso before fixing a couple of other bugs in
qrunner. We're still a touch behind in our Mailman version, and I'd been
hoping an upgrade would cure qrunner -- so this is great, in my view.

-- 
 -D.    dgc@uchicago.edu                                  NSIT::ENSS
From msapiro at value.net  Fri Oct 22 21:41:00 2004
From: msapiro at value.net (Mark Sapiro)
Date: Fri Oct 22 21:41:14 2004
Subject: [Mailman-Developers] Issue with listinfo.html template
Message-ID: <PC17102004102212410000625996ae5e@msapiro>

The following came up on the mailman-users list.

------------ begin quote of my post to mailman-users
Matt Singerman wrote:
>
>I am running an installation of Mailman 2 on an OpenBSD server, running 
>several mailing lists.  The one list in particular I am having problems 
>with is:
>
>http://list.mchoralhealth.org/mailman/listinfo/cohp
>
>The problem is that if you try and view the subscribers' list (which is 
>open to list members), you are redirected to:
>
>http://list.mchoralhealth.org/mailman/subscribe/cohp
>
>Instead of the proper page:
>
>http://list.mchoralhealth.org/mailman/roster/cohp
>
>What on earth could be causing this?  I am contemplating saving out the 
>subscribers list and config file, deleting, and recreating the list.  
>Anyone have any less drastic suggestions?

The listinfo.html template for this list has been messed up in editing.

When the subscribe stuff was moved to the bottom, the line which becomes

    <FORM Method=POST
ACTION="http://list.mchoralhealth.org/mailman/subscribe/cohp">

 in the final page and which probably looks like

    <MM-Subscribe-Form-Start>

in the template needs to be moved down below the other forms on the
page.

The real problem is that in the standard template, the subscribe form
actually begins in the middle of the "About" section instead of within
the "Subscribing" section. This leads to exactly the kind of error you
made when trying to rearrange things on the page.
------------ end of quote

I suggest that the following patch might help people avoid the above
error when editing the template.

--- mailman-2.1.5/templates/en/listinfo.html    2002-11-15
22:10:36.000000000 -0800
+++ mailman-mas/templates/en/listinfo.html      2004-10-22
12:25:30.000000000 -0700
@@ -26,7 +26,6 @@
             <TD COLSPAN="1" WIDTH="100%" BGCOLOR="#FFF0D0">
               <MM-lang-form-start><MM-displang-box> <MM-list-langs>
               <MM-form-end>
-    <MM-Subscribe-Form-Start>
             </TD>
          </TR>
            <tr>
@@ -63,6 +62,7 @@
          <P>
            Subscribe to <MM-List-Name> by filling out the following
              form.
+    <MM-Subscribe-Form-Start>
          <MM-List-Subscription-Msg>
          <ul>
              <TABLE BORDER="0" CELLSPACING="2" CELLPADDING="2"

Of course, if this is a good idea, it also applies (the idea, not the
exact patch) to all the other languages as well.

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

From jrhett at meer.net  Sat Oct 23 03:09:56 2004
From: jrhett at meer.net (Joe Rhett)
Date: Sat Oct 23 03:11:41 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <4173D01C.9090302@nleaudio.com>
References: <20041011174016.GA5462@meer.net>
	<PC17102004101111473702038a58cbd0@msapiro>
	<20041012031057.GA14331@meer.net>
	<A7F8452C-2090-11D9-AE96-000D934FBF38@zone12.com>
	<20041018004118.M81461@nleaudio.com>
	<773259D9-20CF-11D9-AF51-000D934FBF38@zone12.com>
	<4173D01C.9090302@nleaudio.com>
Message-ID: <20041023010956.GB29944@meer.net>

On Mon, Oct 18, 2004 at 10:15:56AM -0400, Bob Puff@NLE wrote:
> If your list machine isn't the same box as the webserver machine, then the 
> web-based create isn't going to work.  :-)  I still think it makes sense.
 
I'm not even dealing with the web-based create, I'm dealing with the
command line.  "list@domain" is clearly an e-mail address to any naked eye.
However, this sets up list with a webserver @ domain, which is completely
counter-intuitive.


-- 
Joe Rhett
Senior Geek
Meer.net
From jrhett at meer.net  Sat Oct 23 03:13:49 2004
From: jrhett at meer.net (Joe Rhett)
Date: Sat Oct 23 03:16:06 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <41741048.4080601@nleaudio.com>
References: <20041011174016.GA5462@meer.net>
	<PC17102004101111473702038a58cbd0@msapiro>
	<20041012031057.GA14331@meer.net>
	<A7F8452C-2090-11D9-AE96-000D934FBF38@zone12.com>
	<20041018004118.M81461@nleaudio.com>
	<773259D9-20CF-11D9-AF51-000D934FBF38@zone12.com>
	<4173D01C.9090302@nleaudio.com>
	<89995ECA-2124-11D9-A1B6-000D934FBF38@zone12.com>
	<41741048.4080601@nleaudio.com>
Message-ID: <20041023011349.GC29944@meer.net>

On Mon, Oct 18, 2004 at 02:49:44PM -0400, Bob Puff@NLE wrote:
> Right.  But when would you use a www.domain?  I never use www.  Do people 
> name their box www?  I usually name the host something else.  I think most 
> people are smart enough to figure out that list_name@domain is not 
> list_name@www.domain.  You face the exact same problem of people doing the 
> same things with two different parameters; i.e., bin/create list_name 
> www.domain etc...
 
I think you are completely missing the point.  In this case list@domain
isn't list@domain at all.  It's actually
	http://domain/mailman/listinfo/listname

Is that obvious?  Not to me.  Let's use something that appears to be an
e-mail address as an obscure shortcut for a long web URL?

If it contains at '@' sign, it should refer to an e-mail address.
If it contains 'http:' sign, it should refer to a web address.
(rule #2 obviously overrides rule#1 when the URL contains an '@' ..)

Create should allow a second parameter to define the web url.  But the '@'
syntax really should refer to the mail domain.

-- 
Joe Rhett
Senior Geek
Meer.net
From mailman at primatesynthesis.com  Sat Oct 23 20:37:39 2004
From: mailman at primatesynthesis.com (Mark)
Date: Sat Oct 23 20:37:52 2004
Subject: [Mailman-Developers] escape characters for boilerplate messages not
	working
Message-ID: <p06002000bda04cbd4996@[192.168.123.146]>


I'm am having trouble putting together a Welcome Message.  Using the 
escape characters for ", &, < and > do not seem to working.  I'm 
getting very odd results whether I try to use the escape characters 
or not.  Not using them results with the escape characters appearing 
in the delivered message (ie. "&" yields "&amp;"), and using them 
results in this weird doubling thing (eg." &amp;" yields 
"&amp;amp;").   Any ideas??

Further, how can I change the text that Mailman automatically appends 
to the Welcome Message??  Can I set it so that it appends nothing??

For you developers, why doesn't it just use plain text, simply 
treating text as text??  It is for generating email, not a webpage.

RTFM Notice:  I have looked through all of the available documents at 
http://www.gnu.org/software/mailman/ and went through the archives 
for the last several months.  The list and archives at 
http://listowner.org/ do not seem to be working at this time.


THANX!!

From msapiro at value.net  Sat Oct 23 23:02:26 2004
From: msapiro at value.net (Mark Sapiro)
Date: Sat Oct 23 23:02:34 2004
Subject: [Mailman-Developers] escape characters for boilerplate messages
	notworking
In-Reply-To: <p06002000bda04cbd4996@[192.168.123.146]>
Message-ID: <PC17102004102314022608289b44d3b6@msapiro>

Mark <mailman@primatesynthesis.com> wrote:
>
>I'm am having trouble putting together a Welcome Message.  Using the 
>escape characters for ", &, < and > do not seem to working.  I'm 
>getting very odd results whether I try to use the escape characters 
>or not.  Not using them results with the escape characters appearing 
>in the delivered message (ie. "&" yields "&amp;"), and using them 
>results in this weird doubling thing (eg." &amp;" yields 
>"&amp;amp;").   Any ideas??

Edit the template directly and put it in the lists/listname directory.
See the FAQ at http://www.python.org/cgi-bin/faqw-mm.py article 4.48.
The template for the welcome message is subscribeack.txt.

>Further, how can I change the text that Mailman automatically appends 
>to the Welcome Message??  Can I set it so that it appends nothing??

 See above.

>For you developers, why doesn't it just use plain text, simply 
>treating text as text??  It is for generating email, not a webpage.
>
>RTFM Notice:  I have looked through all of the available documents at 
>http://www.gnu.org/software/mailman/ and went through the archives 
>for the last several months.  The list and archives at 
>http://listowner.org/ do not seem to be working at this time.

See
http://mail.python.org/pipermail/mailman-users/2004-June/037775.html
re: listowner.org

Did you look at the FAQ?

Did you look at the archives of the mailman-users@python.org list? This
comes up all the time there.

archives -> http://mail.python.org/pipermail/mailman-users/
searchable -> http://www.mail-archive.com/mailman-users%40python.org/

If you didn't find these resources, is there something that could be
added/changed to make them more obvious?

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

From barry at python.org  Mon Oct 25 04:19:34 2004
From: barry at python.org (Barry Warsaw)
Date: Mon Oct 25 04:19:39 2004
Subject: [Mailman-Developers] on the subject of fix_url, list creation
	with @ is non-intuitive..
In-Reply-To: <A7F8452C-2090-11D9-AE96-000D934FBF38@zone12.com>
References: <20041011174016.GA5462@meer.net>
	<PC17102004101111473702038a58cbd0@msapiro>
	<20041012031057.GA14331@meer.net>
	<A7F8452C-2090-11D9-AE96-000D934FBF38@zone12.com>
Message-ID: <1098670774.10128.25.camel@geddy.wooz.org>

On Sun, 2004-10-17 at 19:02, Terri Oda wrote:

> Is there any particular reason we couldn't change the newlist script to 
> accept "name domain" instead of "name@domain" ?  It's just that much 
> less confusing if we don't have this thing that looks like an email 
> address but isn't.  I can't believe anyone's that attached to the 
> confusing syntax, and the increased usability seems worth the small 
> patch this'll take.

I think you'd have to change this in a backward compatible way.  A
counter proposal would be to add name:domain (simply change the '@' to a
':') so it doesn't look like an email address.  Continue to support the
original argument syntax for backward compatibility, but change the
documentation to favor the name:domain syntax.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20041024/20531bca/attachment.pgp
From barry at python.org  Mon Oct 25 04:44:47 2004
From: barry at python.org (Barry Warsaw)
Date: Mon Oct 25 04:44:50 2004
Subject: [Mailman-Developers] We may need to escape percent signs in
	admin forms
In-Reply-To: <ED418EAA8F531A4AA5C8E488@[192.168.0.18]>
References: <20041022100117.A1C101E4020@bag.python.org>
	<ED418EAA8F531A4AA5C8E488@[192.168.0.18]>
Message-ID: <1098672287.10142.49.camel@geddy.wooz.org>

On Fri, 2004-10-22 at 08:50, Tom Neff wrote:

> in htmlformat.py .  I googled this and on a couple of Python forums I found 
> the suggestion than an un-escaped percent sign had found its way into a 
> template.  My templates are untouched but Mailman builds a lot of documents 
> on the fly, so I scanned the pre-submit Sender Filters page source for 
> percents and lo, there were a couple in the list of auto-discard email 
> addresses.  On a whim I removed them and re-Submitted.  Instant success.

Please submit a bug report on this issue.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20041024/4778c59f/attachment.pgp
From tneff at grassyhill.org  Mon Oct 25 04:57:37 2004
From: tneff at grassyhill.org (Tom Neff)
Date: Mon Oct 25 04:57:43 2004
Subject: [Mailman-Developers] We may need to escape percent signs in
	admin forms
In-Reply-To: <1098672287.10142.49.camel@geddy.wooz.org>
References: <20041022100117.A1C101E4020@bag.python.org>
	<ED418EAA8F531A4AA5C8E488@[192.168.0.18]>
	<1098672287.10142.49.camel@geddy.wooz.org>
Message-ID: <BD2336D8D1A240614D7AB819@[192.168.0.18]>

--On Sunday, October 24, 2004 10:44 PM -0400 Barry Warsaw 
<barry@python.org> wrote:
> On Fri, 2004-10-22 at 08:50, Tom Neff wrote:
>
>> in htmlformat.py .  I googled this and on a couple of Python forums I
>> found  the suggestion than an un-escaped percent sign had found its way
>> into a  template.  My templates are untouched but Mailman builds a lot
>> of documents  on the fly, so I scanned the pre-submit Sender Filters
>> page source for  percents and lo, there were a couple in the list of
>> auto-discard email  addresses.  On a whim I removed them and
>> re-Submitted.  Instant success.
>
> Please submit a bug report on this issue.

I hear and obey, effendi.

From terri at zone12.com  Mon Oct 25 08:23:00 2004
From: terri at zone12.com (Terri Oda)
Date: Mon Oct 25 08:22:58 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <1098670774.10128.25.camel@geddy.wooz.org>
References: <20041011174016.GA5462@meer.net>
	<PC17102004101111473702038a58cbd0@msapiro>
	<20041012031057.GA14331@meer.net>
	<A7F8452C-2090-11D9-AE96-000D934FBF38@zone12.com>
	<1098670774.10128.25.camel@geddy.wooz.org>
Message-ID: <51C7DA8C-264E-11D9-8370-000D934FBF38@zone12.com>

On Oct 24, 2004, at 10:19 PM, Barry Warsaw wrote:
> I think you'd have to change this in a backward compatible way.  A
> counter proposal would be to add name:domain (simply change the '@' to 
> a
> ':') so it doesn't look like an email address.  Continue to support the
> original argument syntax for backward compatibility, but change the
> documentation to favor the name:domain syntax.

I was thinking of doing the same thing but with a space instead of a :.
I can't think of any reason not to keep the backwards compatibility as 
long as we don't leave the confusing stuff in the documentation.

If I didn't feel guilty using my laptop while proctoring my students' 
exam, I'd write the patch tomorrow while I'm stuck sitting in a quiet 
room.  I might do it later in the evening, though, if no one else gets 
to it first.

  Terri

From tkikuchi at is.kochi-u.ac.jp  Mon Oct 25 09:44:35 2004
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Mon Oct 25 09:44:51 2004
Subject: [Mailman-Developers] on the subject of fix_url,	list creation
	with @ is non-intuitive..
In-Reply-To: <51C7DA8C-264E-11D9-8370-000D934FBF38@zone12.com>
References: <20041011174016.GA5462@meer.net>	<PC17102004101111473702038a58cbd0@msapiro>	<20041012031057.GA14331@meer.net>	<A7F8452C-2090-11D9-AE96-000D934FBF38@zone12.com>	<1098670774.10128.25.camel@geddy.wooz.org>
	<51C7DA8C-264E-11D9-8370-000D934FBF38@zone12.com>
Message-ID: <417CAEE3.6040101@is.kochi-u.ac.jp>

Hi,

Terri Oda wrote:

> On Oct 24, 2004, at 10:19 PM, Barry Warsaw wrote:
> 
>> I think you'd have to change this in a backward compatible way.  A
>> counter proposal would be to add name:domain (simply change the '@' to a
>> ':') so it doesn't look like an email address.  Continue to support the
>> original argument syntax for backward compatibility, but change the
>> documentation to favor the name:domain syntax.
> 
> 
> I was thinking of doing the same thing but with a space instead of a :.
> I can't think of any reason not to keep the backwards compatibility as 
> long as we don't leave the confusing stuff in the documentation.

Wouldn't it be better to introduce '--urlhost=' option and keep '@' for 
backward compatibility?

$ bin/newlist --urlhost=www.dom.ain listname
or
$ bin/newlist listname@www.dom.ain

> 
> If I didn't feel guilty using my laptop while proctoring my students' 
> exam, I'd write the patch tomorrow while I'm stuck sitting in a quiet 
> room.  I might do it later in the evening, though, if no one else gets 
> to it first.

We need no hurry for release of 2.1.6 is not yet scheduled. ;-)

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

From iane at sussex.ac.uk  Mon Oct 25 12:57:10 2004
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Mon Oct 25 12:57:12 2004
Subject: [Mailman-Developers] on the subject of fix_url, list creation
	with @ is non-intuitive..
In-Reply-To: <417CAEE3.6040101@is.kochi-u.ac.jp>
References: <20041011174016.GA5462@meer.net>
	<PC17102004101111473702038a58cbd0@msapiro>	<20041012031057.GA14331@meer.net>
	<A7F8452C-2090-11D9-AE96-000D934FBF38@zone12.com>
	<1098670774.10128.25.camel@geddy.wooz.org>
	<51C7DA8C-264E-11D9-8370-000D934FBF38@zone12.com>
	<417CAEE3.6040101@is.kochi-u.ac.jp>
Message-ID: <A9A73B244D675B2B1C6C981E@lewes.staff.uscs.susx.ac.uk>



--On Monday, October 25, 2004 4:44 pm +0900 Tokio Kikuchi 
<tkikuchi@is.kochi-u.ac.jp> wrote:

> Hi,
>
> Terri Oda wrote:
>
>> On Oct 24, 2004, at 10:19 PM, Barry Warsaw wrote:
>>
>>> I think you'd have to change this in a backward compatible way.  A
>>> counter proposal would be to add name:domain (simply change the '@' to a
>>> ':') so it doesn't look like an email address.  Continue to support the
>>> original argument syntax for backward compatibility, but change the
>>> documentation to favor the name:domain syntax.
>>
>>
>> I was thinking of doing the same thing but with a space instead of a :.
>> I can't think of any reason not to keep the backwards compatibility as
>> long as we don't leave the confusing stuff in the documentation.
>
> Wouldn't it be better to introduce '--urlhost=' option and keep '@' for
> backward compatibility?
>
> $ bin/newlist --urlhost=www.dom.ain listname
> or
> $ bin/newlist listname@www.dom.ain

No, because there are many types of URL (including mailto:iane@example.com 
email address specifications), so URL is not specific enough. Better would 
be --webhost

>>
>> If I didn't feel guilty using my laptop while proctoring my students'
>> exam, I'd write the patch tomorrow while I'm stuck sitting in a quiet
>> room.  I might do it later in the evening, though, if no one else gets
>> to it first.
>
> We need no hurry for release of 2.1.6 is not yet scheduled. ;-)



-- 
Ian Eiloart
Servers Team
Sussex University ITS

From tkikuchi at is.kochi-u.ac.jp  Mon Oct 25 14:15:04 2004
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Mon Oct 25 14:15:18 2004
Subject: [Mailman-Developers] on the subject of fix_url, list creation
	with @ is non-intuitive..
In-Reply-To: <A9A73B244D675B2B1C6C981E@lewes.staff.uscs.susx.ac.uk>
References: <20041011174016.GA5462@meer.net>	<20041012031057.GA14331@meer.net>	<A7F8452C-2090-11D9-AE96-000D934FBF38@zone12.com>	<1098670774.10128.25.camel@geddy.wooz.org>	<51C7DA8C-264E-11D9-8370-000D934FBF38@zone12.com>	<417CAEE3.6040101@is.kochi-u.ac.jp>
	<A9A73B244D675B2B1C6C981E@lewes.staff.uscs.susx.ac.uk>
Message-ID: <417CEE48.6020909@is.kochi-u.ac.jp>


>> Wouldn't it be better to introduce '--urlhost=' option and keep '@' for
>> backward compatibility?
>>
>> $ bin/newlist --urlhost=www.dom.ain listname
>> or
>> $ bin/newlist listname@www.dom.ain
> 
> 
> No, because there are many types of URL (including 
> mailto:iane@example.com email address specifications), so URL is not 
> specific enough. Better would be --webhost

It is mailman terminology. See Mailman/Defaults.py ... :-<

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

From barry at python.org  Mon Oct 25 14:16:32 2004
From: barry at python.org (Barry Warsaw)
Date: Mon Oct 25 14:16:36 2004
Subject: [Mailman-Developers] on the subject of fix_url, list creation
	with @ is non-intuitive..
In-Reply-To: <51C7DA8C-264E-11D9-8370-000D934FBF38@zone12.com>
References: <20041011174016.GA5462@meer.net>
	<PC17102004101111473702038a58cbd0@msapiro>
	<20041012031057.GA14331@meer.net>
	<A7F8452C-2090-11D9-AE96-000D934FBF38@zone12.com>
	<1098670774.10128.25.camel@geddy.wooz.org>
	<51C7DA8C-264E-11D9-8370-000D934FBF38@zone12.com>
Message-ID: <1098706592.10229.85.camel@geddy.wooz.org>

On Mon, 2004-10-25 at 02:23, Terri Oda wrote:

> I was thinking of doing the same thing but with a space instead of a :.
> I can't think of any reason not to keep the backwards compatibility as 
> long as we don't leave the confusing stuff in the documentation.

The problem with using a space is that it changes the number of
arguments, and bin/newlist accepts additional optional positional
arguments, so that would be a backwards incompatible change.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20041025/4a163b11/attachment.pgp
From barry at python.org  Mon Oct 25 14:17:47 2004
From: barry at python.org (Barry Warsaw)
Date: Mon Oct 25 14:17:51 2004
Subject: [Mailman-Developers] on the subject of fix_url,	list creation
	with @ is non-intuitive..
In-Reply-To: <417CAEE3.6040101@is.kochi-u.ac.jp>
References: <20041011174016.GA5462@meer.net>
	<PC17102004101111473702038a58cbd0@msapiro>
	<20041012031057.GA14331@meer.net>
	<A7F8452C-2090-11D9-AE96-000D934FBF38@zone12.com>
	<1098670774.10128.25.camel@geddy.wooz.org>
	<51C7DA8C-264E-11D9-8370-000D934FBF38@zone12.com>
	<417CAEE3.6040101@is.kochi-u.ac.jp>
Message-ID: <1098706667.10230.87.camel@geddy.wooz.org>

On Mon, 2004-10-25 at 03:44, Tokio Kikuchi wrote:

> Wouldn't it be better to introduce '--urlhost=' option and keep '@' for 
> backward compatibility?
> 
> $ bin/newlist --urlhost=www.dom.ain listname
> or
> $ bin/newlist listname@www.dom.ain

That's a good idea too.
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20041025/f1027f95/attachment.pgp
From terri at zone12.com  Mon Oct 25 16:05:05 2004
From: terri at zone12.com (Terri Oda)
Date: Mon Oct 25 16:05:16 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <417CAEE3.6040101@is.kochi-u.ac.jp>
References: <20041011174016.GA5462@meer.net>	<PC17102004101111473702038a58cbd0@msapiro>	<20041012031057.GA14331@meer.net>	<A7F8452C-2090-11D9-AE96-000D934FBF38@zone12.com>	<1098670774.10128.25.camel@geddy.wooz.org>
	<51C7DA8C-264E-11D9-8370-000D934FBF38@zone12.com>
	<417CAEE3.6040101@is.kochi-u.ac.jp>
Message-ID: <DF3842D4-268E-11D9-8370-000D934FBF38@zone12.com>

On Oct 25, 2004, at 3:44 AM, Tokio Kikuchi wrote:
>> If I didn't feel guilty using my laptop while proctoring my students' 
>> exam, I'd write the patch tomorrow while I'm stuck sitting in a quiet 
>> room.  I might do it later in the evening, though, if no one else 
>> gets to it first.
>
> We need no hurry for release of 2.1.6 is not yet scheduled. ;-)

It's not so much a matter of being in a hurry as it is needing a break 
from marking exams. :)

  Terri

From jrhett at meer.net  Wed Oct 27 02:20:30 2004
From: jrhett at meer.net (Joe Rhett)
Date: Wed Oct 27 02:24:39 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <417CAEE3.6040101@is.kochi-u.ac.jp>
References: <20041011174016.GA5462@meer.net>
	<PC17102004101111473702038a58cbd0@msapiro>
	<20041012031057.GA14331@meer.net>
	<A7F8452C-2090-11D9-AE96-000D934FBF38@zone12.com>
	<1098670774.10128.25.camel@geddy.wooz.org>
	<51C7DA8C-264E-11D9-8370-000D934FBF38@zone12.com>
	<417CAEE3.6040101@is.kochi-u.ac.jp>
Message-ID: <20041027002030.GB20635@meer.net>

On Mon, Oct 25, 2004 at 04:44:35PM +0900, Tokio Kikuchi wrote:
> Wouldn't it be better to introduce '--urlhost=' option and keep '@' for 
> backward compatibility?
> 
> $ bin/newlist --urlhost=www.dom.ain listname
> or
> $ bin/newlist listname@www.dom.ain
 
I agree with the logic, but I'd like a method to create listname@domain
-without- altering the urlhost.

	$ bin/newlist listname@mailhost
	..seems intuitive but breaks compatibility

	$ bin/newlist listname --mailaddr=listname@mailhost
	..would suit my needs as long as urlhost was left alone

-- 
Joe Rhett
Senior Geek
Meer.net
From msapiro at value.net  Wed Oct 27 03:09:25 2004
From: msapiro at value.net (Mark Sapiro)
Date: Wed Oct 27 03:09:46 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <20041027002030.GB20635@meer.net>
Message-ID: <PC17212004102618092505622aec9a2b@msapiro>

Joe Rhett wrote:

>On Mon, Oct 25, 2004 at 04:44:35PM +0900, Tokio Kikuchi wrote:
>> Wouldn't it be better to introduce '--urlhost=' option and keep '@' for 
>> backward compatibility?
>> 
>> $ bin/newlist --urlhost=www.dom.ain listname
>> or
>> $ bin/newlist listname@www.dom.ain
> 
>I agree with the logic, but I'd like a method to create listname@domain
>-without- altering the urlhost.
>
>	$ bin/newlist listname@mailhost
>	..seems intuitive but breaks compatibility
>
>	$ bin/newlist listname --mailaddr=listname@mailhost
>	..would suit my needs as long as urlhost was left alone

You already have the ability to set host_name (which is the e-mail
domain) on the lists General Options page or with bin/config_list.
Granted, it's not as convenient as being able to set it to other than
its default with bin/newlist, but I think most people need to fine
tune a list after creation anyway.

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

From jrhett at meer.net  Wed Oct 27 03:50:59 2004
From: jrhett at meer.net (Joe Rhett)
Date: Wed Oct 27 03:52:27 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <PC17212004102618092505622aec9a2b@msapiro>
References: <20041027002030.GB20635@meer.net>
	<PC17212004102618092505622aec9a2b@msapiro>
Message-ID: <20041027015058.GA38755@meer.net>

On Tue, Oct 26, 2004 at 06:09:25PM -0700, Mark Sapiro wrote:
> You already have the ability to set host_name (which is the e-mail
> domain) on the lists General Options page or with bin/config_list.
> Granted, it's not as convenient as being able to set it to other than
> its default with bin/newlist, but I think most people need to fine
> tune a list after creation anyway.
 
Most _people_ but not most sysadmins.  This isn't my list.  I want to set
up the required settings for the list to function from the command line.

It's not like the setting is easy to find or understand for joe user.  It's
our biggest FAQ. 

-- 
Joe Rhett
Senior Geek
Meer.net
From terri at zone12.com  Wed Oct 27 06:14:47 2004
From: terri at zone12.com (Terri Oda)
Date: Wed Oct 27 06:14:48 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <20041027015058.GA38755@meer.net>
References: <20041027002030.GB20635@meer.net>
	<PC17212004102618092505622aec9a2b@msapiro>
	<20041027015058.GA38755@meer.net>
Message-ID: <BCEA053A-27CE-11D9-8370-000D934FBF38@zone12.com>

On Oct 26, 2004, at 9:50 PM, Joe Rhett wrote:
> On Tue, Oct 26, 2004 at 06:09:25PM -0700, Mark Sapiro wrote:
>> You already have the ability to set host_name (which is the e-mail
>> domain) on the lists General Options page or with bin/config_list.
>> Granted, it's not as convenient as being able to set it to other than
>> its default with bin/newlist, but I think most people need to fine
>> tune a list after creation anyway.
>
> Most _people_ but not most sysadmins.  This isn't my list.  I want to 
> set
> up the required settings for the list to function from the command 
> line.

When I set up a list as a sysadmin, even for someone else, I invariably 
log in to the web interface to make sure it works. :)

> It's not like the setting is easy to find or understand for joe user.  
> It's
> our biggest FAQ.

Interesting...

Do you happen to know where users look for this setting?   If most 
people are looking in the same (wrong) place, then maybe it'd make 
sense to move the setting there.

From jrhett at meer.net  Wed Oct 27 07:26:52 2004
From: jrhett at meer.net (Joe Rhett)
Date: Wed Oct 27 07:29:18 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <BCEA053A-27CE-11D9-8370-000D934FBF38@zone12.com>
References: <20041027002030.GB20635@meer.net>
	<PC17212004102618092505622aec9a2b@msapiro>
	<20041027015058.GA38755@meer.net>
	<BCEA053A-27CE-11D9-8370-000D934FBF38@zone12.com>
Message-ID: <20041027052651.GA72218@meer.net>

On Wed, Oct 27, 2004 at 12:14:47AM -0400, Terri Oda wrote:
> >Most _people_ but not most sysadmins.  This isn't my list.  I want to set
> >up the required settings for the list to function from the command line.
> 
> When I set up a list as a sysadmin, even for someone else, I invariably 
> log in to the web interface to make sure it works. :)

Agreed, but fairly non-trivial to automate ;-0  Thus, command line...

> >It's not like the setting is easy to find or understand for joe user.  
> >It's our biggest FAQ.

> Interesting...
> 
> Do you happen to know where users look for this setting?   If most 
> people are looking in the same (wrong) place, then maybe it'd make 
> sense to move the setting there.

"everywhere" according to them ;-)

It is probably a labeling thing more than a placement issue.  Anyway, the
goal is to have the script set up the mailing list in a working manner
automatically.  If they break it, they break it.  But setting up the list
in a broken manner and requiring the user to fix it is less useful.

-- 
Joe Rhett
Senior Geek
Meer.net
From phill.thomas at solutions-inc.co.uk  Wed Oct 27 13:13:56 2004
From: phill.thomas at solutions-inc.co.uk (Phill Thomas)
Date: Wed Oct 27 13:13:16 2004
Subject: [Mailman-Developers] Other MTA's
Message-ID: <BDA54184.B9F5%phill.thomas@solutions-inc.co.uk>

Hi all,

I hope this is the right list to be posting too, if not please let me
know....

I currently run Communigate Pro on a Xserve running Mac OS 10.3.5, the list
server built into Communigate is not brilliant and as such I decided to use
Mailman instead.

However I now find myself unsure how I can make Mailman use Communigate as
the MTA? Or if this is even possible?

Any advice or ideas on this would be greatly appreciated.

Regards,

Phillip Thomas


From msapiro at value.net  Wed Oct 27 17:19:14 2004
From: msapiro at value.net (Mark Sapiro)
Date: Wed Oct 27 17:19:36 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <20041027052651.GA72218@meer.net>
Message-ID: <PC17212004102708191400007610f54e@msapiro>

Joe Rhett wrote:

>On Wed, Oct 27, 2004 at 12:14:47AM -0400, Terri Oda wrote:
>> >Most _people_ but not most sysadmins.  This isn't my list.  I want to set
>> >up the required settings for the list to function from the command line.
>> 
>> When I set up a list as a sysadmin, even for someone else, I invariably 
>> log in to the web interface to make sure it works. :)
>
>Agreed, but fairly non-trivial to automate ;-0  Thus, command line...

Is I indicated in a previous post, bin/config_list can change it. It
should be fairly simple to script writing "host_name = 'something'" to
a file and then doing bin/config_list -i that_file listname.

>
>> >It's not like the setting is easy to find or understand for joe user.  
>> >It's our biggest FAQ.
>
>> Interesting...
>> 
>> Do you happen to know where users look for this setting?   If most 
>> people are looking in the same (wrong) place, then maybe it'd make 
>> sense to move the setting there.
>
>"everywhere" according to them ;-)
>
>It is probably a labeling thing more than a placement issue.  Anyway, the
>goal is to have the script set up the mailing list in a working manner
>automatically.  If they break it, they break it.  But setting up the list
>in a broken manner and requiring the user to fix it is less useful.

I am curious. I'm not questioning your need, I'm just wondering why you
have a need to create a list in a particular web domain with an email
host different from the one set for that domain in VIRTUAL_HOSTS.

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

From jrhett at meer.net  Wed Oct 27 19:16:15 2004
From: jrhett at meer.net (Joe Rhett)
Date: Wed Oct 27 19:22:19 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <PC17212004102708191400007610f54e@msapiro>
References: <20041027052651.GA72218@meer.net>
	<PC17212004102708191400007610f54e@msapiro>
Message-ID: <20041027171615.GA98934@meer.net>

>> Most _people_ but not most sysadmins.  This isn't my list.  I want to set
>> up the required settings for the list to function from the command line.
	..
>> Agreed, but fairly non-trivial to automate ;-0  Thus, command line...

> Is I indicated in a previous post, bin/config_list can change it. It
> should be fairly simple to script writing "host_name = 'something'" to
> a file and then doing bin/config_list -i that_file listname.

It's also simple to run fix_url in a similar manner.  So why is the url
setting provided with newlist?

>From our experience, most lists need the list mailaddr changed.  Very very
few need the urlhost changed.  So I am asking why newlist doesn't do both.

> I am curious. I'm not questioning your need, I'm just wondering why you
> have a need to create a list in a particular web domain with an email
> host different from the one set for that domain in VIRTUAL_HOSTS.
 
I think you completely misunderstand.  I don't want to change the web
domain -- that is the problem! The list server has only one name,
ever.  There are no virtual hosts involved.  There are no web domains.

The goal is to allow people to have their lists inside their own domain,
without having to find the value and fix it in their web admin.

Thus, lists.meer.net (the only name, no virtual hosts) hosts lists known as
mylist@mydomain.com, hislist@hisdomain.net, herlist@herdomain.net, etc.

The admin interface for the domain will always be http://lists.meer.net/...
It's the mailaddr for the domain which is almost always changed.

-- 
Joe Rhett
Senior Geek
Meer.net
From barry at python.org  Wed Oct 27 19:31:00 2004
From: barry at python.org (Barry Warsaw)
Date: Wed Oct 27 19:31:07 2004
Subject: [Mailman-Developers] on the subject of fix_url, list creation
	with @ is non-intuitive..
In-Reply-To: <20041027171615.GA98934@meer.net>
References: <20041027052651.GA72218@meer.net>
	<PC17212004102708191400007610f54e@msapiro>
	<20041027171615.GA98934@meer.net>
Message-ID: <1098898259.20808.18.camel@geddy.wooz.org>

On Wed, 2004-10-27 at 13:16, Joe Rhett wrote:

> It's also simple to run fix_url in a similar manner.  So why is the url
> setting provided with newlist?

newlist predates both fix_url and config_list.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20041027/6f935499/attachment.pgp
From jrhett at MEER.NET  Wed Oct 27 19:35:58 2004
From: jrhett at MEER.NET (Joe Rhett)
Date: Wed Oct 27 19:41:49 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <1098898259.20808.18.camel@geddy.wooz.org>
References: <20041027052651.GA72218@meer.net>
	<PC17212004102708191400007610f54e@msapiro>
	<20041027171615.GA98934@meer.net>
	<1098898259.20808.18.camel@geddy.wooz.org>
Message-ID: <20041027173558.GB4435@meer.net>

On Wed, Oct 27, 2004 at 01:31:00PM -0400, Barry Warsaw wrote:
> On Wed, 2004-10-27 at 13:16, Joe Rhett wrote:
> 
> > It's also simple to run fix_url in a similar manner.  So why is the url
> > setting provided with newlist?
> 
> newlist predates both fix_url and config_list.

Make sense.

But anyway, my arguement is that having a vanity mailaddr for the list is
fairly common (over 90% in most implementations I've seen) so can't we get
this put into newlist as being generally useful?


-- 
Joe Rhett
Senior Geek
Meer.net
From bob at nleaudio.com  Wed Oct 27 19:48:38 2004
From: bob at nleaudio.com (Bob Puff@NLE)
Date: Wed Oct 27 19:52:13 2004
Subject: [Mailman-Developers] on the subject of fix_url,	list creation
	with @ is non-intuitive..
In-Reply-To: <20041027173558.GB4435@meer.net>
References: <20041027052651.GA72218@meer.net>	<PC17212004102708191400007610f54e@msapiro>	<20041027171615.GA98934@meer.net>	<1098898259.20808.18.camel@geddy.wooz.org>
	<20041027173558.GB4435@meer.net>
Message-ID: <417FDF76.7020902@nleaudio.com>

...But vanity domains are normally virtualhosts, which already work.  I think it is 
counter-intuitive to have:
Email:  list@domain
and then have the web interface be at: http://some.other.domain/some other folder/list

Bob

Joe Rhett wrote:

> On Wed, Oct 27, 2004 at 01:31:00PM -0400, Barry Warsaw wrote:
> 
>>On Wed, 2004-10-27 at 13:16, Joe Rhett wrote:
>>
>>
>>>It's also simple to run fix_url in a similar manner.  So why is the url
>>>setting provided with newlist?
>>
>>newlist predates both fix_url and config_list.
> 
> 
> Make sense.
> 
> But anyway, my arguement is that having a vanity mailaddr for the list is
> fairly common (over 90% in most implementations I've seen) so can't we get
> this put into newlist as being generally useful?
> 
> 
From terri at zone12.com  Wed Oct 27 20:45:27 2004
From: terri at zone12.com (Terri Oda)
Date: Wed Oct 27 20:45:34 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <417FDF76.7020902@nleaudio.com>
References: <20041027052651.GA72218@meer.net>	<PC17212004102708191400007610f54e@msapiro>	<20041027171615.GA98934@meer.net>	<1098898259.20808.18.camel@geddy.wooz.org>
	<20041027173558.GB4435@meer.net> <417FDF76.7020902@nleaudio.com>
Message-ID: <5EE27000-2848-11D9-97BD-000D934FBF38@zone12.com>

On Oct 27, 2004, at 1:48 PM, Bob Puff@NLE wrote:
> ...But vanity domains are normally virtualhosts, which already work.  
> I think it is counter-intuitive to have:
> Email:  list@domain
> and then have the web interface be at: http://some.other.domain/some 
> other folder/list

Normally they may be virtual hosts, but not *always*.  I know I host 
some lists for people whose web domains aren't hosted on the same 
machine.  I gather paying to host lists can be quite a bit more 
expensive than web hosting, so I imagine a number of people host lists 
on DSL and such while their websites are hosted somewhere more stable.  
While it's quite reasonable to set up redirects and such, if you're 
going for lower-cost web hosting, you may not have the option to do so.

Anyhow, for all that making newlist have some extra options *isn't* 
necessary, it seems like it'll make it that much more useful, so we 
might as well just do it.  It's not like anyone has to use the extra 
options if they don't want to, and the whole thing can be backwards 
compatible.

  Terri

From barry at python.org  Wed Oct 27 20:50:59 2004
From: barry at python.org (Barry Warsaw)
Date: Wed Oct 27 20:51:04 2004
Subject: [Mailman-Developers] on the subject of fix_url, list creation
	with @ is non-intuitive..
In-Reply-To: <5EE27000-2848-11D9-97BD-000D934FBF38@zone12.com>
References: <20041027052651.GA72218@meer.net>
	<PC17212004102708191400007610f54e@msapiro>
	<20041027171615.GA98934@meer.net>
	<1098898259.20808.18.camel@geddy.wooz.org>
	<20041027173558.GB4435@meer.net> <417FDF76.7020902@nleaudio.com>
	<5EE27000-2848-11D9-97BD-000D934FBF38@zone12.com>
Message-ID: <1098903059.20807.28.camel@geddy.wooz.org>

On Wed, 2004-10-27 at 14:45, Terri Oda wrote:

> Anyhow, for all that making newlist have some extra options *isn't* 
> necessary, it seems like it'll make it that much more useful, so we 
> might as well just do it.  It's not like anyone has to use the extra 
> options if they don't want to, and the whole thing can be backwards 
> compatible.

I'm -0 on it.  I think it's generally not needed given all the other
tools at your disposal, but if a patch is provided that does this in a
clean, backward compatible way, I won't veto it.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20041027/c048d22a/attachment.pgp
From jrhett at meer.net  Thu Oct 28 05:59:14 2004
From: jrhett at meer.net (Joe Rhett)
Date: Thu Oct 28 06:01:54 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <417FDF76.7020902@nleaudio.com>
References: <20041027052651.GA72218@meer.net>
	<PC17212004102708191400007610f54e@msapiro>
	<20041027171615.GA98934@meer.net>
	<1098898259.20808.18.camel@geddy.wooz.org>
	<20041027173558.GB4435@meer.net> <417FDF76.7020902@nleaudio.com>
Message-ID: <20041028035914.GA34060@meer.net>

Vanity domains are almost NEVER virtual hosts.

A virtual host requires me to configure my server to answer mail for their
entire domain.  That makes ZERO sense.  Jesus Bob, have you ever worked on
anything besides a home pc?

lists.meer.net has hundreds of lists. 98% of those lists are 
	listname@vanitydomain1
	listname@vanitydomain2
	listname@vanitydomain3

NONE of these are virtualhosts on lists.meer.net.

On Wed, Oct 27, 2004 at 01:48:38PM -0400, Bob Puff@NLE wrote:
> ...But vanity domains are normally virtualhosts, which already work.  I 
> think it is counter-intuitive to have:
> Email:  list@domain
> and then have the web interface be at: http://some.other.domain/some other 
> folder/list
> 
> Bob
> 
> Joe Rhett wrote:
> 
> >On Wed, Oct 27, 2004 at 01:31:00PM -0400, Barry Warsaw wrote:
> >
> >>On Wed, 2004-10-27 at 13:16, Joe Rhett wrote:
> >>
> >>
> >>>It's also simple to run fix_url in a similar manner.  So why is the url
> >>>setting provided with newlist?
> >>
> >>newlist predates both fix_url and config_list.
> >
> >
> >Make sense.
> >
> >But anyway, my arguement is that having a vanity mailaddr for the list is
> >fairly common (over 90% in most implementations I've seen) so can't we get
> >this put into newlist as being generally useful?
> >
> >
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Unsubscribe: 
> http://mail.python.org/mailman/options/mailman-developers/jrhett%40meer.net

-- 
Joe Rhett
Senior Geek
Meer.net
From jrhett at meer.net  Thu Oct 28 06:03:54 2004
From: jrhett at meer.net (Joe Rhett)
Date: Thu Oct 28 06:08:19 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <1098903059.20807.28.camel@geddy.wooz.org>
References: <20041027052651.GA72218@meer.net>
	<PC17212004102708191400007610f54e@msapiro>
	<20041027171615.GA98934@meer.net>
	<1098898259.20808.18.camel@geddy.wooz.org>
	<20041027173558.GB4435@meer.net> <417FDF76.7020902@nleaudio.com>
	<5EE27000-2848-11D9-97BD-000D934FBF38@zone12.com>
	<1098903059.20807.28.camel@geddy.wooz.org>
Message-ID: <20041028040353.GB34060@meer.net>

> I'm -0 on it.  I think it's generally not needed given all the other
> tools at your disposal, but if a patch is provided that does this in a
> clean, backward compatible way, I won't veto it.

What tools are those?  A heavy web ui?

Sorry, did I overlook a command/command/command/commit ability in Mailman?

Without that, you are limited to a long chain of command lines where we 
have to check each return code and then back out the commands if any one 
fails.  This makes no sense for any automation effort, and generally
requires several hundred lines of code that do not survive upgrades, to
work around a problem that can be solved in several lines of python in the
source.

-- 
Joe Rhett
Senior Geek
Meer.net
From PLombrozo at veeco.com  Thu Oct 28 08:06:50 2004
From: PLombrozo at veeco.com (Peter Lombrozo)
Date: Thu Oct 28 08:06:53 2004
Subject: [Mailman-Developers] Customizing archive page
Message-ID: <625BD6DD96DE554DBB0558FFE70E0F426D4223@sboexch2.int.veeco.com>

I'm trying to modify the archtocnombox.html page to look more like our company web site.  I was able to add in a form for htDig search which worked fine, but when I added a lot of tables and additional information in the page, MM or pipermail quit parsing the embedded variables (e.g.,%(archive_listing_start)s) and leaves them on the page.  Is there some trick to get it to this, or does the script lose its mind trying to read in all the extra html and give up?  Thanks.

Peter Lombrozo
plombrozo@veeco.com
From fil at rezo.net  Thu Oct 28 15:12:40 2004
From: fil at rezo.net (Fil)
Date: Thu Oct 28 15:12:40 2004
Subject: [Mailman-Developers] locking and big lists
Message-ID: <20041028131240.GC23608@rezo.net>


Hello,

I have had a big problem with Mailman yesterday and today: two or three
hours after I sent out my "big list" message (150 000 subscribers), Mailman
started to spend all its time using CPU, for ages. In fact, it was the
bounce runner that had started to send out the "probe" messages, one by one,
making VirginRunner lock the list repeatedly, and holding the lock for 15s
each time. Meanwhile the web admin interface was unreachable (for that
list), and other scripts waited and failed.

I finally looked everywhere to find out what was happening, and cleaned up
the qfiles/virgin/ queue of all the probes, and waited another two hours for
the qflies/command/ queue to empty... not very good.

As I have a very big server (4 CPUs, 6Gbytes of RAM), I suppose that only a
MySQL-backed Mailman would answer this problem. How far is it from being
usable?

-- Fil

From tkikuchi at is.kochi-u.ac.jp  Thu Oct 28 15:33:52 2004
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Thu Oct 28 15:34:06 2004
Subject: [Mailman-Developers] locking and big lists
In-Reply-To: <20041028131240.GC23608@rezo.net>
References: <20041028131240.GC23608@rezo.net>
Message-ID: <4180F540.5020406@is.kochi-u.ac.jp>

Hi,

> I have had a big problem with Mailman yesterday and today: two or three
> hours after I sent out my "big list" message (150 000 subscribers), Mailman
> started to spend all its time using CPU, for ages. In fact, it was the
> bounce runner that had started to send out the "probe" messages, one by one,
> making VirginRunner lock the list repeatedly, and holding the lock for 15s
> each time. Meanwhile the web admin interface was unreachable (for that
> list), and other scripts waited and failed.

You may want to disable VERP_PROBES by update your mailman to the latest
CVS. It was introduced in 2.1.5 but made optional for backward
compatibility. I remember you have updated around 16 Oct but CVS commit
was done 22 for this fix. (Remember you need specify Release_2_1-maint)

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

From fil at rezo.net  Thu Oct 28 15:41:43 2004
From: fil at rezo.net (Fil)
Date: Thu Oct 28 15:41:43 2004
Subject: [Mailman-Developers] locking and big lists
In-Reply-To: <4180F540.5020406@is.kochi-u.ac.jp>
References: <20041028131240.GC23608@rezo.net>
	<4180F540.5020406@is.kochi-u.ac.jp>
Message-ID: <20041028134142.GD23608@rezo.net>

> You may want to disable VERP_PROBES by update your mailman to the latest
> CVS. It was introduced in 2.1.5 but made optional for backward
> compatibility. I remember you have updated around 16 Oct but CVS commit
> was done 22 for this fix. (Remember you need specify Release_2_1-maint)

In fact I would like to disable probes altogether, on all lists. Is this
with a cron job, or with the bounce runner ?

-- Fil

From brad at stop.mail-abuse.org  Thu Oct 28 16:01:03 2004
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Thu Oct 28 16:03:23 2004
Subject: [Mailman-Developers] locking and big lists
In-Reply-To: <20041028131240.GC23608@rezo.net>
References: <20041028131240.GC23608@rezo.net>
Message-ID: <p0600207bbda6ab33e792@[10.0.1.3]>

At 3:12 PM +0200 2004-10-28, Fil wrote:

>  As I have a very big server (4 CPUs, 6Gbytes of RAM), I suppose that only a
>  MySQL-backed Mailman would answer this problem. How far is it from being
>  usable?

	For a large-scale mail system, number and speed of CPUs is 
meaningless.  Amount of RAM doesn't really mean a whole lot.  What 
you need is disk I/O capacity.

	Have you put your entire spool filesystem on solid-state disk, or 
at least very high capacity multi-spindle RAID 1+0 arrays with high 
speed battery-backed controllers with large quantities of write-back 
cache?


	See also 
<http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.003.htp>, 
as one of many items in the Mailman FAQ that discuss "performance". 
Of course, you should also see the others, too.

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

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

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

   SAGE member since 1995.  See <http://www.sage.org/> for more info.
From fil at rezo.net  Thu Oct 28 16:37:55 2004
From: fil at rezo.net (Fil)
Date: Thu Oct 28 16:37:56 2004
Subject: [Mailman-Developers] locking and big lists
In-Reply-To: <p0600207bbda6ab33e792@[10.0.1.3]>
References: <20041028131240.GC23608@rezo.net>
	<p0600207bbda6ab33e792@[10.0.1.3]>
Message-ID: <20041028143753.GA27233@rezo.net>

> 	Have you put your entire spool filesystem on solid-state disk, or 
> at least very high capacity multi-spindle RAID 1+0 arrays with high 
> speed battery-backed controllers with large quantities of write-back 
> cache?

I don't understand this language, sorry. We have just upgraded the I/O
capacity of the server, and it's working fine with every other piece of
software, no problem with postfix handling tons of emails for example.

But still when we're talking about a 15-60 seconds lock for each subscriber,
even if we could have the hardware go twice faster, it's way too slow.
That's why I believe only the database backend can help (or any other
software modification). What's especially wierd is that probe sending is
very costly, but personalization or VERP-delivery is not that costly.

-- Fil

From brad at stop.mail-abuse.org  Thu Oct 28 17:14:37 2004
From: brad at stop.mail-abuse.org (Brad Knowles)
Date: Thu Oct 28 17:48:14 2004
Subject: [Mailman-Developers] locking and big lists
In-Reply-To: <20041028143753.GA27233@rezo.net>
References: <20041028131240.GC23608@rezo.net>
	<p0600207bbda6ab33e792@[10.0.1.3]>
	<20041028143753.GA27233@rezo.net>
Message-ID: <p0600207dbda6ba59746b@[10.0.1.3]>

At 4:37 PM +0200 2004-10-28, Fil wrote:

>  I don't understand this language, sorry. We have just upgraded the I/O
>  capacity of the server, and it's working fine with every other piece of
>  software, no problem with postfix handling tons of emails for example.

	The same sorts of problems generally face Mailman as face other 
programs, and the same sorts of solutions are usually useful for 
Mailman.  So, solid-state disks, high-capacity RAID 1+0 arrays with 
high-speed controllers and large amounts of battery-backed write-back 
cache, etc....

	If you're confused about a lot of these terms, I'd recommend 
reading the book by Nick Christenson entitled _sendmail Performance 
Tuning_, which is linked from that first page I mentioned.

>  But still when we're talking about a 15-60 seconds lock for each subscriber,
>  even if we could have the hardware go twice faster, it's way too slow.

	I think it would be profitable to find out why VirginRunner is 
holding the lock this long.

>  That's why I believe only the database backend can help (or any other
>  software modification). What's especially wierd is that probe sending is
>  very costly, but personalization or VERP-delivery is not that costly.

	There are people who have done database back-end stuff for 
Mailman 2.x, but so far as I know none of that has been integrated 
back into the mainstream code base.  Those are all one-off 
operations.  There will be a database back-end built into Mailman3, 
but it's still in the design phase right now.

	If you can't find out why VirginRunner is holding the locks so 
long, then the best thing to do would be turn off the VERP bounce 
probes.

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

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

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

   SAGE member since 1995.  See <http://www.sage.org/> for more info.
From dallas at dreamhost.com  Thu Oct 28 19:43:33 2004
From: dallas at dreamhost.com (Dallas Bethune)
Date: Thu Oct 28 19:43:37 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <20041028040353.GB34060@meer.net>
References: <20041027052651.GA72218@meer.net>
	<PC17212004102708191400007610f54e@msapiro>
	<20041027171615.GA98934@meer.net>
	<1098898259.20808.18.camel@geddy.wooz.org>
	<20041027173558.GB4435@meer.net> <417FDF76.7020902@nleaudio.com>
	<5EE27000-2848-11D9-97BD-000D934FBF38@zone12.com>
	<1098903059.20807.28.camel@geddy.wooz.org>
	<20041028040353.GB34060@meer.net>
Message-ID: <E365FF57-2908-11D9-9CD8-000A95AA76E0@dreamhost.com>


On Oct 27, 2004, at 9:03 PM, Joe Rhett wrote:

>> I'm -0 on it.  I think it's generally not needed given all the other
>> tools at your disposal, but if a patch is provided that does this in a
>> clean, backward compatible way, I won't veto it.
>
> What tools are those?  A heavy web ui?
>
> Sorry, did I overlook a command/command/command/commit ability in 
> Mailman?
>
> Without that, you are limited to a long chain of command lines where we
> have to check each return code and then back out the commands if any 
> one
> fails.  This makes no sense for any automation effort, and generally
> requires several hundred lines of code that do not survive upgrades, to
> work around a problem that can be solved in several lines of python in 
> the
> source.


We use config_list to set some specific options for each of our lists.  
We have completely automated the mailman list setup and it has worked 
without any human intervention for our 5000+ lists.  Just create a 
config_list template file by outputting the configuration for an 
existing list and then write your script to set the variables you want 
and then load those into the list.

It would, of course, be easier with one single command that does 
everything you need but config_list is very useful and not that 
difficult.  The changes we made to accommodate the 2.0 -> 2.1 upgrade 
were minor.  We've had this system in place for several years now.

	Dallas


................................................
DreamHost Web Hosting
http://www.dreamhost.com/

From tkikuchi at is.kochi-u.ac.jp  Fri Oct 29 02:10:55 2004
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Fri Oct 29 02:11:07 2004
Subject: [Mailman-Developers] locking and big lists
In-Reply-To: <20041028134142.GD23608@rezo.net>
References: <20041028131240.GC23608@rezo.net>	<4180F540.5020406@is.kochi-u.ac.jp>
	<20041028134142.GD23608@rezo.net>
Message-ID: <41818A8F.3010203@is.kochi-u.ac.jp>


>>You may want to disable VERP_PROBES by update your mailman to the latest
>>CVS. It was introduced in 2.1.5 but made optional for backward
>>compatibility. I remember you have updated around 16 Oct but CVS commit
>>was done 22 for this fix. (Remember you need specify Release_2_1-maint)
> 
> 
> In fact I would like to disable probes altogether, on all lists. Is this
> with a cron job, or with the bounce runner ?

In fact mailman (CVS) will not send probes if VERP_PROBES = No. :-)

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

From fil at rezo.net  Fri Oct 29 09:43:25 2004
From: fil at rezo.net (Fil)
Date: Fri Oct 29 09:43:20 2004
Subject: [Mailman-Developers] locking and big lists
In-Reply-To: <41818A8F.3010203@is.kochi-u.ac.jp>
References: <20041028131240.GC23608@rezo.net>
	<4180F540.5020406@is.kochi-u.ac.jp>
	<20041028134142.GD23608@rezo.net>
	<41818A8F.3010203@is.kochi-u.ac.jp>
Message-ID: <20041029074325.GA8452@rezo.net>

> >In fact I would like to disable probes altogether, on all lists. Is this
> >with a cron job, or with the bounce runner ?
> 
> In fact mailman (CVS) will not send probes if VERP_PROBES = No. :-)

What's weird now is that it processes things just "as if" it was sending
probes, but indeed, in fact it doesn't send them. That's not solving my
problem of CPU/lock :-)

logs/bounce is full of:
Oct 29 09:41:59 2004 (21355) renxxxxxx@xxxxxx.fr: info-diplo current bounce score: 3.0
Oct 29 09:41:59 2004 (21355) sending info-diplo list probe to: renxxxxxx@xxxxxx.fr (score 3.0 >= 3.0)

-- Fil

From jrhett at meer.net  Fri Oct 29 10:14:08 2004
From: jrhett at meer.net (Joe Rhett)
Date: Fri Oct 29 10:25:28 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <E365FF57-2908-11D9-9CD8-000A95AA76E0@dreamhost.com>
References: <20041027052651.GA72218@meer.net>
	<PC17212004102708191400007610f54e@msapiro>
	<20041027171615.GA98934@meer.net>
	<1098898259.20808.18.camel@geddy.wooz.org>
	<20041027173558.GB4435@meer.net> <417FDF76.7020902@nleaudio.com>
	<5EE27000-2848-11D9-97BD-000D934FBF38@zone12.com>
	<1098903059.20807.28.camel@geddy.wooz.org>
	<20041028040353.GB34060@meer.net>
	<E365FF57-2908-11D9-9CD8-000A95AA76E0@dreamhost.com>
Message-ID: <20041029081408.GB59540@meer.net>

> We use config_list to set some specific options for each of our lists.  
> We have completely automated the mailman list setup and it has worked 
> without any human intervention for our 5000+ lists.  Just create a 
> config_list template file by outputting the configuration for an 
> existing list and then write your script to set the variables you want 
> and then load those into the list.
 
Yes, yes, with many lines of code I can output from an existing list (and
check return code and validate the data just in case that list is foobar)
and then parse/replace variables, and then reload those into the list and
again check return codes and validate everything works.

In fact, I have already done all of that work.  I did it differently, by
invoking newlist and then using just the new parameters with config_list.
I was wondering if I should submit it for the contrib section.

Then, it struck me that this entire 180 lines script could be completely 
replaced by a single option on the newlist command.  And that single option
would be useful for many different environments, without any of the
built-in assumptions that a script like yours or mine has to make.

So I'm not trying to say: make this work for me -- already does

I am trying to say: This is too much work for how simple the solution is,
and a general purpose solution would solve the problem for many, many sites.

-- 
Joe Rhett
Senior Geek
Meer.net
From glenn at aoi-industries.com  Fri Oct 29 16:09:44 2004
From: glenn at aoi-industries.com (Glenn Burkhardt)
Date: Fri Oct 29 16:09:48 2004
Subject: [Mailman-Developers] status of search archive feature
Message-ID: <200410291009.44700.glenn@aoi-industries.com>

I notice that there are patches available to integrate an archive search 
feature into Mailman, and at least one of the patches (#444884) has been 
maintained for years over the various versions of Mailman.

Is there a plan for adding this incredibly useful feature to Mailman?  Why 
hasn't patch 444884 been incorporated into the code as a supported feature?

Thanks. 
From barry at python.org  Fri Oct 29 16:36:27 2004
From: barry at python.org (Barry Warsaw)
Date: Fri Oct 29 16:36:36 2004
Subject: [Mailman-Developers] on the subject of fix_url, list creation
	with @ is non-intuitive..
In-Reply-To: <20041028035914.GA34060@meer.net>
References: <20041027052651.GA72218@meer.net>
	<PC17212004102708191400007610f54e@msapiro>
	<20041027171615.GA98934@meer.net>
	<1098898259.20808.18.camel@geddy.wooz.org>
	<20041027173558.GB4435@meer.net>
	<417FDF76.7020902@nleaudio.com>  <20041028035914.GA34060@meer.net>
Message-ID: <1099060587.22116.19.camel@geddy.wooz.org>

On Wed, 2004-10-27 at 23:59, Joe Rhett wrote:

> A virtual host requires me to configure my server to answer mail for their
> entire domain.

Really?  I provide mailing list services for lots of my friend's bands
(and most of my own), and they only need to create a new host name in
their domain, and point that at my server.  I only need to answer mail
and web for that host.  It's easy to set up and almost effortless to
administer.  YMMV of course.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20041029/287ff96f/attachment.pgp
From barry at python.org  Fri Oct 29 16:48:07 2004
From: barry at python.org (Barry Warsaw)
Date: Fri Oct 29 16:48:10 2004
Subject: [Mailman-Developers] on the subject of fix_url, list creation
	with @ is non-intuitive..
In-Reply-To: <20041028040353.GB34060@meer.net>
References: <20041027052651.GA72218@meer.net>
	<PC17212004102708191400007610f54e@msapiro>
	<20041027171615.GA98934@meer.net>
	<1098898259.20808.18.camel@geddy.wooz.org>
	<20041027173558.GB4435@meer.net> <417FDF76.7020902@nleaudio.com>
	<5EE27000-2848-11D9-97BD-000D934FBF38@zone12.com>
	<1098903059.20807.28.camel@geddy.wooz.org>
	<20041028040353.GB34060@meer.net>
Message-ID: <1099061287.22118.24.camel@geddy.wooz.org>

On Thu, 2004-10-28 at 00:03, Joe Rhett wrote:

> What tools are those?  A heavy web ui?

Personally, I'd write a scriptlet for bin/withlist to do it.  Should be
just a few lines of Python since withlist takes care of getting
everything set up properly, deals with lock, etc.  

config_list as someone else mentioned is a fine way to go (remember that
its input only needs to contain the variables that you want to change).

The other thing to remember is that there's nothing magical about the
bin scripts that come with Mailman.  They serve as fine examples of how
to interact with Mailman from the command line.  A Python programmer
should have no trouble writing custom scripts to deal with any odd
situation that can't already be handled by withlist or config_list.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20041029/c7f15a6b/attachment.pgp
From PLombrozo at veeco.com  Fri Oct 29 20:45:27 2004
From: PLombrozo at veeco.com (Peter Lombrozo)
Date: Fri Oct 29 20:45:30 2004
Subject: [Mailman-Developers] Bug in Membership list search?
Message-ID: <625BD6DD96DE554DBB0558FFE70E0F426D4235@sboexch2.int.veeco.com>

I think I found a bug in Mailman 2.1.5 Membership list search.  When my search hits needs several pages to display the members, a letter list at the top links to the other alphabetical pages.  However, when I hit the letter, it gives me all the members starting with that letter, instead of just the ones meeting the search criteria.  I would need to put in the criteria for each letter.  Is this a known bug, or is there a patch to change this behaviour?  Thanks.

Peter Lombrozo
Plombrozo@veeco.com
Software Engineer
From jrhett at meer.net  Sat Oct 30 00:03:03 2004
From: jrhett at meer.net (Joe Rhett)
Date: Sat Oct 30 00:05:04 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <1099060587.22116.19.camel@geddy.wooz.org>
References: <20041027052651.GA72218@meer.net>
	<PC17212004102708191400007610f54e@msapiro>
	<20041027171615.GA98934@meer.net>
	<1098898259.20808.18.camel@geddy.wooz.org>
	<20041027173558.GB4435@meer.net> <417FDF76.7020902@nleaudio.com>
	<20041028035914.GA34060@meer.net>
	<1099060587.22116.19.camel@geddy.wooz.org>
Message-ID: <20041029220303.GA34097@meer.net>

On Fri, Oct 29, 2004 at 10:36:27AM -0400, Barry Warsaw wrote:
> On Wed, 2004-10-27 at 23:59, Joe Rhett wrote:
> 
> > A virtual host requires me to configure my server to answer mail for their
> > entire domain.
> 
> Really?  I provide mailing list services for lots of my friend's bands
> (and most of my own), and they only need to create a new host name in
> their domain, and point that at my server.  I only need to answer mail
 
And again, our mailing list server is not a web server for their domain,
nor an MTA for their domain.  And never will be.

-- 
Joe Rhett
Senior Geek
Meer.net
From jrhett at meer.net  Sat Oct 30 00:09:30 2004
From: jrhett at meer.net (Joe Rhett)
Date: Sat Oct 30 00:11:10 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <1099060587.22116.19.camel@geddy.wooz.org>
References: <20041027052651.GA72218@meer.net>
	<PC17212004102708191400007610f54e@msapiro>
	<20041027171615.GA98934@meer.net>
	<1098898259.20808.18.camel@geddy.wooz.org>
	<20041027173558.GB4435@meer.net> <417FDF76.7020902@nleaudio.com>
	<20041028035914.GA34060@meer.net>
	<1099060587.22116.19.camel@geddy.wooz.org>
Message-ID: <20041029220929.GA36160@meer.net>

On Fri, Oct 29, 2004 at 10:36:27AM -0400, Barry Warsaw wrote:
> Really?  I provide mailing list services for lots of my friend's bands
> (and most of my own), and they only need to create a new host name in
> their domain, and point that at my server.  I only need to answer mail
> and web for that host.  It's easy to set up and almost effortless to
> administer.  YMMV of course.
 
Because that list is limited to your friends, and is probably less than a
thousand, right?

And second, let's think about this:

1. We add an extra option to newlist that allows us to set the listaddr at
creation time.

	-or-

1. You have the list owner change their DNS to point to you
2. You host their website and their domain
3. You provide a mechanism for them to update their web pages
4. You provide a mechanism for them to access their e-mail
5. You become a general support/ISP for said domain, even though you only
agreed to host a list for them.

Ah, I see.  The latter is OBVIOUSLY a much better idea!

Seriously people, if you have a single server that does everything and you
want to host your friend's e-mail lists on it then yes, virtual hosting
makes sense.  If you are not in the business of providing support and
general web hosting to the world at large for free, this is nonsense.

-- 
Joe Rhett
Senior Geek
Meer.net
From jrhett at meer.net  Sat Oct 30 00:13:42 2004
From: jrhett at meer.net (Joe Rhett)
Date: Sat Oct 30 00:16:36 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <1099061287.22118.24.camel@geddy.wooz.org>
References: <20041027052651.GA72218@meer.net>
	<PC17212004102708191400007610f54e@msapiro>
	<20041027171615.GA98934@meer.net>
	<1098898259.20808.18.camel@geddy.wooz.org>
	<20041027173558.GB4435@meer.net> <417FDF76.7020902@nleaudio.com>
	<5EE27000-2848-11D9-97BD-000D934FBF38@zone12.com>
	<1098903059.20807.28.camel@geddy.wooz.org>
	<20041028040353.GB34060@meer.net>
	<1099061287.22118.24.camel@geddy.wooz.org>
Message-ID: <20041029221341.GB36160@meer.net>

Already did it, as stated in my other post.  If you are hacking around on
your friend's websites it might be "a few lines", but a production script
that must either succeed or tell you why not in useful terms takes hundreds
of lines.

But then I doubt that people who can't think beyond their personal system
hosting their friends websites really grasp the goals I am trying to meet
anyway. 

And no, you can't code it in Python without wrapping the python script
execution in a language that handles exceptions in a useful manner.  I'm
not a language bigot (kindof hard these days, I work in 5 different
languages daily) but if a language doesn't have the ability to do something
then you must write wrappers around it.

On Fri, Oct 29, 2004 at 10:48:07AM -0400, Barry Warsaw wrote:
> On Thu, 2004-10-28 at 00:03, Joe Rhett wrote:
> 
> > What tools are those?  A heavy web ui?
> 
> Personally, I'd write a scriptlet for bin/withlist to do it.  Should be
> just a few lines of Python since withlist takes care of getting
> everything set up properly, deals with lock, etc.  
> 
> config_list as someone else mentioned is a fine way to go (remember that
> its input only needs to contain the variables that you want to change).
> 
> The other thing to remember is that there's nothing magical about the
> bin scripts that come with Mailman.  They serve as fine examples of how
> to interact with Mailman from the command line.  A Python programmer
> should have no trouble writing custom scripts to deal with any odd
> situation that can't already be handled by withlist or config_list.
> 
> -Barry
> 



-- 
Joe Rhett
Senior Geek
Meer.net
From barry at python.org  Sat Oct 30 00:17:04 2004
From: barry at python.org (Barry Warsaw)
Date: Sat Oct 30 00:17:10 2004
Subject: [Mailman-Developers] on the subject of fix_url, list creation
	with @ is non-intuitive..
In-Reply-To: <20041029220929.GA36160@meer.net>
References: <20041027052651.GA72218@meer.net>
	<PC17212004102708191400007610f54e@msapiro>
	<20041027171615.GA98934@meer.net>
	<1098898259.20808.18.camel@geddy.wooz.org>
	<20041027173558.GB4435@meer.net>
	<417FDF76.7020902@nleaudio.com> <20041028035914.GA34060@meer.net>
	<1099060587.22116.19.camel@geddy.wooz.org>
	<20041029220929.GA36160@meer.net>
Message-ID: <1099088224.1521.16.camel@geddy.wooz.org>

On Fri, 2004-10-29 at 18:09, Joe Rhett wrote:

> And second, let's think about this:

Sorry, I'm out of time to discuss this thread, so I'll just leave it at
this: I've already given my vote on doing this in a backward compatible
way.  What's left is to generate a patch that satisfies my earlier
requirements, and then sweet talk Tokio into commit it. :)

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20041029/531edca0/attachment.pgp
From terri at zone12.com  Sat Oct 30 00:23:22 2004
From: terri at zone12.com (Terri Oda)
Date: Sat Oct 30 00:23:18 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <20041029220929.GA36160@meer.net>
References: <20041027052651.GA72218@meer.net>
	<PC17212004102708191400007610f54e@msapiro>
	<20041027171615.GA98934@meer.net>
	<1098898259.20808.18.camel@geddy.wooz.org>
	<20041027173558.GB4435@meer.net> <417FDF76.7020902@nleaudio.com>
	<20041028035914.GA34060@meer.net>
	<1099060587.22116.19.camel@geddy.wooz.org>
	<20041029220929.GA36160@meer.net>
Message-ID: <24E18232-29F9-11D9-A26F-000D934FBF38@zone12.com>


> 1. You have the list owner change their DNS to point to you
> 2. You host their website and their domain
> 3. You provide a mechanism for them to update their web pages
> 4. You provide a mechanism for them to access their e-mail
> 5. You become a general support/ISP for said domain, even though you 
> only
> agreed to host a list for them.


Nono.  You set up mailman.theirdomain.com or lists.theirdomain.com and 
point *it* at your server.   You don't host anything but lists, all the 
lists then have addresses that are mylist@lists.theirdomain.com and if 
they want to alias mylist@theirdomain.com, then that's their job and 
none of your business.

Now, I can totally see how you could wind up getting stuck hosting 
other stuff once you did this ("We want there to a page on 
http://mailman.theirdomain.com/ instead of just /mailman/listinfo", "we 
want the list to give mylist@theirdomain.com on the listinfo pages", 
etc.)  But to be fair, there is no need for you do handle anything 
other than a subdomain which need not be used for anything but lists.

But anyhow, you seem to have a good idea of what you'd like, and you've 
clearly got the ability to make the patch if you're handling this stuff 
right now.  Would you be willing to write it?  All it takes now is a 
patch that's good enough for commiting, and you should be able to have 
what you want.

  Terri

From jrhett at meer.net  Sat Oct 30 01:15:06 2004
From: jrhett at meer.net (Joe Rhett)
Date: Sat Oct 30 01:16:56 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <24E18232-29F9-11D9-A26F-000D934FBF38@zone12.com>
References: <20041027052651.GA72218@meer.net>
	<PC17212004102708191400007610f54e@msapiro>
	<20041027171615.GA98934@meer.net>
	<1098898259.20808.18.camel@geddy.wooz.org>
	<20041027173558.GB4435@meer.net> <417FDF76.7020902@nleaudio.com>
	<20041028035914.GA34060@meer.net>
	<1099060587.22116.19.camel@geddy.wooz.org>
	<20041029220929.GA36160@meer.net>
	<24E18232-29F9-11D9-A26F-000D934FBF38@zone12.com>
Message-ID: <20041029231505.GA49036@meer.net>

On Fri, Oct 29, 2004 at 06:23:22PM -0400, Terri Oda wrote:
> Nono.  You set up mailman.theirdomain.com or lists.theirdomain.com and 
> point *it* at your server.   You don't host anything but lists, all the 
> lists then have addresses that are mylist@lists.theirdomain.com and if 
> they want to alias mylist@theirdomain.com, then that's their job and 
> none of your business.
 
And this still does not solve the original problem I was trying to solve.

The listname is somelist@vanity.com.  Creating somelist@lists.vanity.com or
somelist@mailman.vanity.com does not solve the original problem. You could
go through all the effort of creating this host/domain, and you're still
stuck with the problem that the listaddr is not the same as the admin url.

The truth is that I have only rarely witnessed a situation where the
listaddr and the hostaddr are the same, except when people are running
lists from their own personal computers.  That's why I questioned the value
the original option.

> But anyhow, you seem to have a good idea of what you'd like, and you've 
> clearly got the ability to make the patch if you're handling this stuff 
> right now.  Would you be willing to write it?  All it takes now is a 
> patch that's good enough for commiting, and you should be able to have 
> what you want.
 
I'd appreciate anything you could do on this.  I want something agreeable
and maintained in future versions, including 3.0

-- 
Joe Rhett
Senior Geek
Meer.net
From jrhett at meer.net  Sat Oct 30 01:17:18 2004
From: jrhett at meer.net (Joe Rhett)
Date: Sat Oct 30 01:18:39 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <1099088224.1521.16.camel@geddy.wooz.org>
References: <20041027052651.GA72218@meer.net>
	<PC17212004102708191400007610f54e@msapiro>
	<20041027171615.GA98934@meer.net>
	<1098898259.20808.18.camel@geddy.wooz.org>
	<20041027173558.GB4435@meer.net> <417FDF76.7020902@nleaudio.com>
	<20041028035914.GA34060@meer.net>
	<1099060587.22116.19.camel@geddy.wooz.org>
	<20041029220929.GA36160@meer.net>
	<1099088224.1521.16.camel@geddy.wooz.org>
Message-ID: <20041029231717.GB49036@meer.net>

On Fri, Oct 29, 2004 at 06:17:04PM -0400, Barry Warsaw wrote:
> On Fri, 2004-10-29 at 18:09, Joe Rhett wrote:
> 
> > And second, let's think about this:
> 
> Sorry, I'm out of time to discuss this thread, so I'll just leave it at
> this: I've already given my vote on doing this in a backward compatible
> way.  What's left is to generate a patch that satisfies my earlier
> requirements, and then sweet talk Tokio into commit it. :)
 
That's fine.  Since we're sticking with the obscure, unintuitive syntax
(to maintain backwards compatibility for an option that not a single person
on the list said that they used and most didn't even understand)
could I persuade you to update the documentation to state clearly that
listname@domain.name is not an e-mail address, but a shortcut syntax to set
the admin url to be http://domain.name/admin/listname?

It's still godawful, and near useless.

-- 
Joe Rhett
Senior Geek
Meer.net
From terri at zone12.com  Sat Oct 30 01:39:33 2004
From: terri at zone12.com (Terri Oda)
Date: Sat Oct 30 01:40:29 2004
Subject: [Mailman-Developers] on the subject of fix_url,
	list creation with @ is non-intuitive..
In-Reply-To: <20041029231717.GB49036@meer.net>
References: <20041027052651.GA72218@meer.net>
	<PC17212004102708191400007610f54e@msapiro>
	<20041027171615.GA98934@meer.net>
	<1098898259.20808.18.camel@geddy.wooz.org>
	<20041027173558.GB4435@meer.net> <417FDF76.7020902@nleaudio.com>
	<20041028035914.GA34060@meer.net>
	<1099060587.22116.19.camel@geddy.wooz.org>
	<20041029220929.GA36160@meer.net>
	<1099088224.1521.16.camel@geddy.wooz.org>
	<20041029231717.GB49036@meer.net>
Message-ID: <C93E05FC-2A03-11D9-A26F-000D934FBF38@zone12.com>


On Oct 29, 2004, at 7:17 PM, Joe Rhett wrote:
> That's fine.  Since we're sticking with the obscure, unintuitive syntax
> (to maintain backwards compatibility for an option that not a single 
> person
> on the list said that they used and most didn't even understand)
> could I persuade you to update the documentation to state clearly that
> listname@domain.name is not an e-mail address, but a shortcut syntax 
> to set
> the admin url to be http://domain.name/admin/listname?

Ooh, that's my job... but the only documentation I know of for newlist 
already explains that.  The only documentation I know of for the 
command is in the --help for the command itself.

Is there somewhere else it doesn't, or can you suggest a better way to 
say it?

  Terri

From tkikuchi at is.kochi-u.ac.jp  Sat Oct 30 02:29:24 2004
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Sat Oct 30 02:29:52 2004
Subject: [Mailman-Developers] on the subject of fix_url, list creation
	with @ is non-intuitive..
In-Reply-To: <1099088224.1521.16.camel@geddy.wooz.org>
References: <20041027052651.GA72218@meer.net>	<PC17212004102708191400007610f54e@msapiro>	<20041027171615.GA98934@meer.net>	<1098898259.20808.18.camel@geddy.wooz.org>	<20041027173558.GB4435@meer.net>	<417FDF76.7020902@nleaudio.com>
	<20041028035914.GA34060@meer.net>	<1099060587.22116.19.camel@geddy.wooz.org>	<20041029220929.GA36160@meer.net>
	<1099088224.1521.16.camel@geddy.wooz.org>
Message-ID: <4182E064.2090705@is.kochi-u.ac.jp>

Hi,

Barry Warsaw wrote:

> On Fri, 2004-10-29 at 18:09, Joe Rhett wrote:
> 
> 
>>And second, let's think about this:
> 
> 
> Sorry, I'm out of time to discuss this thread, so I'll just leave it at
> this: I've already given my vote on doing this in a backward compatible
> way.  What's left is to generate a patch that satisfies my earlier
> requirements, and then sweet talk Tokio into commit it. :)

I am far behind the discussion but I think we can add one more option to
newlist command like this:

newlist --urlhost=www.dom.ain --emailhost=mail.dom.ain listname

We also keep @ notation for backward compatibility:

newlist listname@www.dom.ain

Anyone volunteer to make a patch?

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

From tkikuchi at is.kochi-u.ac.jp  Sat Oct 30 02:40:19 2004
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Sat Oct 30 02:40:29 2004
Subject: [Mailman-Developers] locking and big lists
In-Reply-To: <20041029074325.GA8452@rezo.net>
References: <20041028131240.GC23608@rezo.net>	<4180F540.5020406@is.kochi-u.ac.jp>	<20041028134142.GD23608@rezo.net>	<41818A8F.3010203@is.kochi-u.ac.jp>
	<20041029074325.GA8452@rezo.net>
Message-ID: <4182E2F3.40907@is.kochi-u.ac.jp>

Fil wrote:

>>>In fact I would like to disable probes altogether, on all lists. Is this
>>>with a cron job, or with the bounce runner ?
>>
>>In fact mailman (CVS) will not send probes if VERP_PROBES = No. :-)
> 
> 
> What's weird now is that it processes things just "as if" it was sending
> probes, but indeed, in fact it doesn't send them. That's not solving my
> problem of CPU/lock :-)
> 
> logs/bounce is full of:
> Oct 29 09:41:59 2004 (21355) renxxxxxx@xxxxxx.fr: info-diplo current bounce score: 3.0
> Oct 29 09:41:59 2004 (21355) sending info-diplo list probe to: renxxxxxx@xxxxxx.fr (score 3.0 >= 3.0)

Are you sure you restart mailman qrunners ?
"list probe" no longer appears in my log. Instead, like this:

Oct 28 10:42:06 2004 (55889) seppyo-talk: xxxx@xxxx disabling due to 
bounce score 5.0 >= 5.0

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

From barry at python.org  Sat Oct 30 05:39:21 2004
From: barry at python.org (Barry Warsaw)
Date: Sat Oct 30 05:39:33 2004
Subject: [Mailman-Developers] on the subject of fix_url, list creation
	with @ is non-intuitive..
In-Reply-To: <4182E064.2090705@is.kochi-u.ac.jp>
References: <20041027052651.GA72218@meer.net>
	<PC17212004102708191400007610f54e@msapiro>
	<20041027171615.GA98934@meer.net>
	<1098898259.20808.18.camel@geddy.wooz.org>	<20041027173558.GB4435@meer.net>
	<417FDF76.7020902@nleaudio.com> <20041028035914.GA34060@meer.net>
	<1099060587.22116.19.camel@geddy.wooz.org>
	<20041029220929.GA36160@meer.net>
	<1099088224.1521.16.camel@geddy.wooz.org>
	<4182E064.2090705@is.kochi-u.ac.jp>
Message-ID: <1099107561.21149.45.camel@presto.wooz.org>

On Fri, 2004-10-29 at 20:29, Tokio Kikuchi wrote:

> I am far behind the discussion but I think we can add one more option to
> newlist command like this:
> 
> newlist --urlhost=www.dom.ain --emailhost=mail.dom.ain listname
> 
> We also keep @ notation for backward compatibility:
> 
> newlist listname@www.dom.ain

+1

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20041029/96fa96a7/attachment.pgp
From fil at rezo.net  Sat Oct 30 12:00:12 2004
From: fil at rezo.net (Fil)
Date: Sat Oct 30 12:00:54 2004
Subject: [Mailman-Developers] locking and big lists
In-Reply-To: <4182E2F3.40907@is.kochi-u.ac.jp>
References: <20041028131240.GC23608@rezo.net>
	<4180F540.5020406@is.kochi-u.ac.jp>
	<20041028134142.GD23608@rezo.net>
	<41818A8F.3010203@is.kochi-u.ac.jp>
	<20041029074325.GA8452@rezo.net> <4182E2F3.40907@is.kochi-u.ac.jp>
Message-ID: <20041030100012.GA345@rezo.net>

> >>In fact mailman (CVS) will not send probes if VERP_PROBES = No. :-)
> >
> >What's weird now is that it processes things just "as if" it was sending
> >probes, but indeed, in fact it doesn't send them. That's not solving my
> >problem of CPU/lock :-)
> >
> >logs/bounce is full of:
> >Oct 29 09:41:59 2004 (21355) renxxxxxx@xxxxxx.fr: info-diplo current 
> >bounce score: 3.0
> >Oct 29 09:41:59 2004 (21355) sending info-diplo list probe to: 
> >renxxxxxx@xxxxxx.fr (score 3.0 >= 3.0)
> 
> Are you sure you restart mailman qrunners ?

Yes. But I hadn't updated the CVS  :-)
Sorry for the trouble

-- Fil

From tkikuchi at is.kochi-u.ac.jp  Sun Oct 31 12:19:36 2004
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Sun Oct 31 12:19:52 2004
Subject: [Mailman-Developers] on the subject of fix_url, list creation
	with @ is non-intuitive..
In-Reply-To: <4182E064.2090705@is.kochi-u.ac.jp>
References: <20041027052651.GA72218@meer.net>	<PC17212004102708191400007610f54e@msapiro>	<20041027171615.GA98934@meer.net>	<1098898259.20808.18.camel@geddy.wooz.org>	<20041027173558.GB4435@meer.net>	<417FDF76.7020902@nleaudio.com>	<1099060587.22116.19.camel@geddy.wooz.org>	<20041029220929.GA36160@meer.net>	<1099088224.1521.16.camel@geddy.wooz.org>
	<4182E064.2090705@is.kochi-u.ac.jp>
Message-ID: <4184CA48.30209@is.kochi-u.ac.jp>

Tokio Kikuchi wrote:

> I am far behind the discussion but I think we can add one more option to
> newlist command like this:
> 
> newlist --urlhost=www.dom.ain --emailhost=mail.dom.ain listname
> 
> We also keep @ notation for backward compatibility:
> 
> newlist listname@www.dom.ain
> 
> Anyone volunteer to make a patch?

I did. Please check the patch on SF.
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1057579&group_id=103

BTW, newlist listname@dom.ain set both urlhost and _emailhost_ if
'dom.ain' is not defined in VERTUAL_HOSTS.

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