From wheakory at isu.edu  Mon Dec  1 10:59:36 2003
From: wheakory at isu.edu (Kory Wheatley)
Date: Mon Dec  1 10:59:44 2003
Subject: [Mailman-Developers] New Mailman version proposal
Message-ID: <3FCB6568.4060600@isu.edu>

For the next mailman version I would like to see a option where you can 
filter mail to a list and have it be discarded rather than have the 
emails filtered to the moderator for approval, because the moderator 
still has to go into the admin interface and delete all these spam 
messages that have been put on hold waiting for an action.  I would just 
like to see these messages automatically discarded.  If this is already 
possible in the current version I would sure like to know how.

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



From darwin at desktopengineer.com  Mon Dec  1 15:03:09 2003
From: darwin at desktopengineer.com (darwin@desktopengineer.com)
Date: Wed Dec  3 14:16:59 2003
Subject: [Mailman-Developers] Mailman Preprocessor Available - seeking
	feedback
Message-ID: <00c501c3b846$28031ce0$1502a8c0@PHASE5>

Hello,
Below is the description of a preprocessor script I wrote for mailman.  I
was looking to emulate the Topica.com features of "<list>-subscribe",
"<list>-unsubscribe" and "<list>-post-<password>" in an efficient and
extensible manner.
 
I am seeking feedback on the script and I have two areas that are troubling
right now:
*) I still get a succesful completion AND an error message back from mailman
when sending to "<list>-unsubscribe" (yet I don't get one when sending to
"<list>-unsubscribe" which *should* process exactly the same way.  I know I
coiuld re-write the entire message - but I am wondering if there is a way to
make unsubscribe work the same way as subscribe and post - by doing
replacements to the inbound message.
*) I am wondering if there is a way to alter all the messages sent out by
mailman to match my configuration.  There are some in "Templates" - but
others seem hardcoded.  Right now I am tied to Mailman 2.0.13 due to needing
to stay compliant with the RedHat 2.1AS distribution.    
 
The script can be found at http://desktopengineer.com/mmpreproc
 
Thanks for any time anyone can take to send feedback,
D.
 
# This script pre-processes mail commands to mailman to faciliate
announcement lists and easy subscribe and unsubscribe.
# It modifies the list behavior as follows:
#   *) unsubscribes only made through the alias <list>-subscribe@domain.com
and automatically sets users password to their email
#   *) unsubscribes only made through the alias
<list>-unsubscribe@domain.com and automatically unsubscribes with no
confirm, email=password is assumed
#   *) posting to the list can only be done through a special alias that
includes a password component such as <list>-post-<password>@domain.com.
#      The list can be configured for moderation and only allow a specific
list of emails to be automatically approved.  Since it is recommended
#      that you delete the <list>@domain.com alias, using this method
prevents the need to moderate messages that try to use the standard posting
#      alias - even if you do not allow auto approval of posts to specific
email addresses.
#   *) This script accomplishes its objectives by having the mail message
piped to it and then it pipes the message into the standard mailman wrapper
for
#      processing.  This is more efficient than re-mailing back to the same
system.  In addition, since the program simply does regex substitutions to 
#      inbound message headers, the posting password alias can work easily
with complex messages that include mime sections because the entire message
does not
#      need to pass through mail again and therefore be disassembled,
reassembled and then emailed correctly.
#   *) Many other modifications could be made for preprocessing mailman
commands and posts - the script design is modular and dynamic - it pulls
apart the
#      mail aliases components (seperate by "-" character) and decides what
to do with the message based on these components.
 
# Install
#   *) Tested with mailman 2.0.13 (Redhat 2.1AS Version)
#   *) Ensure you have Mail:Mailer (mailtools) installed if you wish to have
error notification or debug emails sent, or rewrite the email section 
#      to suite your system.
#   *) Copy mmprepoc.pl to <mailmanroot>/mail (e.g. "cp mmpreproc.pl
/path/to/mailman/mail")
#   *) Change ownership to the mailman user (e.g. "chown mailman
mmpreproc.pl")
#   *) Change security to be executable (e.g. "chmod 755 mmpreproc.pl")
#   *) For sendmail create a link in the /etc/smrsh directory (e.g. "ln -s
/path/to/mailman/mail/mmpreproc.pl")
#   *) Set $mailmanpath - this should be the directory with all your mailman
subdirectories (including "bin") in it.
#   *) Set $blockrequests - if set to "1" this script blocks all
<list>-request@domain.com messages except replys to 
#      subscription confirmations.
#   *) Set $emaildiscards, $emailerrors, $emaildebug and $emailnotifyaddress
if you wish to use email notification.
 
# Configure Mailman (note your lists cannot have a "-" character in their
name):
#   *) add the list alias <listname>-subscribe:
"|/path/to/mailman/mail/mmpreproc.pl"
#   *) add the list alias <listname>-unsubscribe:
"|/path/to/mailman/mail/mmpreproc.pl"
 
# Configure Mailman: If using the post-password alias feature
#   *) add the list alias <listname>-post-<password>:
"|/path/to/mailman/mail/subprocessor"
#   *) remove the list alias <list> or send it to null so that you don't
have to moderate messages sent there.
#   *) in mail man set posting to the list to be only allowed from members
of the list and setup any auto-approval email
#      addresses.  It won't matter that users can see your auto approved
email when receiving messages because they cannot
#      tell that you used a special alias to send the message rather than
<list>@domain.com

 
From Darwin at sanoy.com  Mon Dec  1 14:57:02 2003
From: Darwin at sanoy.com (Darwin Sanoy)
Date: Wed Dec  3 14:17:09 2003
Subject: [Mailman-Developers] Mailman Preprocessor Available - seeking
	feedback
Message-ID: <00bb01c3b845$4d15e2c0$1502a8c0@PHASE5>

Hello,
Below is the description of a preprocessor script I wrote for mailman.  I
was looking to emulate the Topica.com features of "<list>-subscribe",
"<list>-unsubscribe" and "<list>-post-<password>" in an efficient and
extensible manner.
 
I am seeking feedback on the script and I have two areas that are troubling
right now:
*) I still get a succesful completion AND an error message back from mailman
when sending to "<list>-unsubscribe" (yet I don't get one when sending to
"<list>-unsubscribe" which *should* process exactly the same way.  I know I
coiuld re-write the entire message - but I am wondering if there is a way to
make unsubscribe work the same way as subscribe and post - by doing
replacements to the inbound message.
*) I am wondering if there is a way to alter all the messages sent out by
mailman to match my configuration.  There are some in "Templates" - but
others seem hardcoded.  Right now I am tied to Mailman 2.0.13 due to needing
to stay compliant with the RedHat 2.1AS distribution.    
 
The script can be found at http://desktopengineer.com/mmpreproc
 
Thanks for any time anyone can take to send feedback,
D.
 
# This script pre-processes mail commands to mailman to faciliate
announcement lists and easy subscribe and unsubscribe.
# It modifies the list behavior as follows:
#   *) unsubscribes only made through the alias <list>-subscribe@domain.com
and automatically sets users password to their email
#   *) unsubscribes only made through the alias
<list>-unsubscribe@domain.com and automatically unsubscribes with no
confirm, email=password is assumed
#   *) posting to the list can only be done through a special alias that
includes a password component such as <list>-post-<password>@domain.com.
#      The list can be configured for moderation and only allow a specific
list of emails to be automatically approved.  Since it is recommended
#      that you delete the <list>@domain.com alias, using this method
prevents the need to moderate messages that try to use the standard posting
#      alias - even if you do not allow auto approval of posts to specific
email addresses.
#   *) This script accomplishes its objectives by having the mail message
piped to it and then it pipes the message into the standard mailman wrapper
for
#      processing.  This is more efficient than re-mailing back to the same
system.  In addition, since the program simply does regex substitutions to 
#      inbound message headers, the posting password alias can work easily
with complex messages that include mime sections because the entire message
does not
#      need to pass through mail again and therefore be disassembled,
reassembled and then emailed correctly.
#   *) Many other modifications could be made for preprocessing mailman
commands and posts - the script design is modular and dynamic - it pulls
apart the
#      mail aliases components (seperate by "-" character) and decides what
to do with the message based on these components.
 
# Install
#   *) Tested with mailman 2.0.13 (Redhat 2.1AS Version)
#   *) Ensure you have Mail:Mailer (mailtools) installed if you wish to have
error notification or debug emails sent, or rewrite the email section 
#      to suite your system.
#   *) Copy mmprepoc.pl to <mailmanroot>/mail (e.g. "cp mmpreproc.pl
/path/to/mailman/mail")
#   *) Change ownership to the mailman user (e.g. "chown mailman
mmpreproc.pl")
#   *) Change security to be executable (e.g. "chmod 755 mmpreproc.pl")
#   *) For sendmail create a link in the /etc/smrsh directory (e.g. "ln -s
/path/to/mailman/mail/mmpreproc.pl")
#   *) Set $mailmanpath - this should be the directory with all your mailman
subdirectories (including "bin") in it.
#   *) Set $blockrequests - if set to "1" this script blocks all
<list>-request@domain.com messages except replys to 
#      subscription confirmations.
#   *) Set $emaildiscards, $emailerrors, $emaildebug and $emailnotifyaddress
if you wish to use email notification.
 
# Configure Mailman (note your lists cannot have a "-" character in their
name):
#   *) add the list alias <listname>-subscribe:
"|/path/to/mailman/mail/mmpreproc.pl"
#   *) add the list alias <listname>-unsubscribe:
"|/path/to/mailman/mail/mmpreproc.pl"
 
# Configure Mailman: If using the post-password alias feature
#   *) add the list alias <listname>-post-<password>:
"|/path/to/mailman/mail/subprocessor"
#   *) remove the list alias <list> or send it to null so that you don't
have to moderate messages sent there.
#   *) in mail man set posting to the list to be only allowed from members
of the list and setup any auto-approval email
#      addresses.  It won't matter that users can see your auto approved
email when receiving messages because they cannot
#      tell that you used a special alias to send the message rather than
<list>@domain.com

 
From pioppo at ferrara.linux.it  Wed Dec  3 15:33:39 2003
From: pioppo at ferrara.linux.it (Simone Piunno)
Date: Wed Dec  3 15:12:37 2003
Subject: [Mailman-Developers] Mailman Preprocessor Available - seeking
	feedback
In-Reply-To: <00c501c3b846$28031ce0$1502a8c0@PHASE5>
References: <00c501c3b846$28031ce0$1502a8c0@PHASE5>
Message-ID: <200312032133.39489.pioppo@ferrara.linux.it>

On Monday 01 December 2003 21:03, darwin@desktopengineer.com wrote:

> Below is the description of a preprocessor script I wrote for mailman.  I
[...]
> The script can be found at http://desktopengineer.com/mmpreproc
> Thanks for any time anyone can take to send feedback,

Hi Darwin,

thanks for your contribution, nonetheless I think your script has some 
problem:

1. the link you above is a 404 ;)
2. it's in perl ;) ;)
3. mostly reimplements a script that's floating on the net since 1999:
http://www.bee-side.org/free_software/various/postfix-to-mailman-2.1woody.py
   
My advice is to try to rewrite your script in python, starting from the 
example above, so that maybe it has a chance to be integrated in Mailman 
itself.

-- 
Adde parvum parvo magnus acervus erit -- Ovidio


From Darwin at DesktopEngineer.com  Wed Dec  3 15:43:36 2003
From: Darwin at DesktopEngineer.com (Darwin Sanoy)
Date: Wed Dec  3 15:43:52 2003
Subject: [Mailman-Developers] Mailman Preprocessor Available - seeking
	feedback
In-Reply-To: <200312032133.39489.pioppo@ferrara.linux.it>
Message-ID: <001801c3b9de$23c97770$1502a8c0@PHASE5>

Sorry the link should be http://desktopengineertraining.com/mmpreproc.

Wish I had found this other earlier.  Should be linked on the mailman info
pages.

It is in Perl because I do not intend to learn another language to support
this one hack.

Not sure why my version would be included in mailman if the functionality in
the version that has been around since 99 has not been incorporated.

D.

____________________________
Darwin Sanoy
Principal Consultant and Trainer
DesktopEngineer.com
DesktopEngineerTraining.com
--- Don't Think Out of the Box, Burn It ---


-----Original Message-----
From: Simone Piunno [mailto:pioppo@ferrara.linux.it] 
Sent: Wednesday, December 03, 2003 3:34 PM
To: darwin@desktopengineer.com; Mailman-developers@python.org
Subject: Re: [Mailman-Developers] Mailman Preprocessor Available - seeking
feedback


On Monday 01 December 2003 21:03, darwin@desktopengineer.com wrote:

> Below is the description of a preprocessor script I wrote for mailman.  
> I
[...]
> The script can be found at http://desktopengineer.com/mmpreproc
> Thanks for any time anyone can take to send feedback,

Hi Darwin,

thanks for your contribution, nonetheless I think your script has some 
problem:

1. the link you above is a 404 ;)
2. it's in perl ;) ;)
3. mostly reimplements a script that's floating on the net since 1999:
http://www.bee-side.org/free_software/various/postfix-to-mailman-2.1woody.py
   
My advice is to try to rewrite your script in python, starting from the 
example above, so that maybe it has a chance to be integrated in Mailman 
itself.

-- 
Adde parvum parvo magnus acervus erit -- Ovidio


From Darwin at DesktopEngineer.com  Fri Dec  5 08:44:34 2003
From: Darwin at DesktopEngineer.com (Darwin Sanoy)
Date: Fri Dec  5 08:44:54 2003
Subject: [Mailman-Developers] Mailman Preprocessor Available - seeking
	feedback
In-Reply-To: <200312032133.39489.pioppo@ferrara.linux.it>
Message-ID: <00c001c3bb35$f038a210$1502a8c0@PHASE5>

Since I am not python savvy can someone tell me if this gets around the user
password required for unsubscribe like my script does?

Thanks,
D.

____________________________
Darwin Sanoy
Principal Consultant and Trainer
DesktopEngineer.com
DesktopEngineerTraining.com
--- Don't Think Out of the Box, Burn It ---


-----Original Message-----
From: Simone Piunno [mailto:pioppo@ferrara.linux.it] 
Sent: Wednesday, December 03, 2003 3:34 PM
To: darwin@desktopengineer.com; Mailman-developers@python.org
Subject: Re: [Mailman-Developers] Mailman Preprocessor Available - seeking
feedback


On Monday 01 December 2003 21:03, darwin@desktopengineer.com wrote:

> Below is the description of a preprocessor script I wrote for mailman.  
> I
[...]
> The script can be found at http://desktopengineer.com/mmpreproc
> Thanks for any time anyone can take to send feedback,

Hi Darwin,

thanks for your contribution, nonetheless I think your script has some 
problem:

1. the link you above is a 404 ;)
2. it's in perl ;) ;)
3. mostly reimplements a script that's floating on the net since 1999:
http://www.bee-side.org/free_software/various/postfix-to-mailman-2.1woody.py
   
My advice is to try to rewrite your script in python, starting from the 
example above, so that maybe it has a chance to be integrated in Mailman 
itself.

-- 
Adde parvum parvo magnus acervus erit -- Ovidio


From pioppo at ferrara.linux.it  Fri Dec  5 09:46:09 2003
From: pioppo at ferrara.linux.it (Simone Piunno)
Date: Fri Dec  5 09:46:16 2003
Subject: [Mailman-Developers] Mailman Preprocessor Available - seeking
	feedback
In-Reply-To: <00c001c3bb35$f038a210$1502a8c0@PHASE5>
References: <00c001c3bb35$f038a210$1502a8c0@PHASE5>
Message-ID: <200312051546.09315.pioppo@ferrara.linux.it>

Alle 14:44, venerd? 5 dicembre 2003, Darwin Sanoy ha scritto:

> Since I am not python savvy can someone tell me if this gets around the
> user password required for unsubscribe like my script does?

No, it does not.

-- 
This signature intentionally left blank



From mundaun at gmx.ch  Sat Dec  6 05:58:48 2003
From: mundaun at gmx.ch (Michael Stucki)
Date: Sat Dec  6 06:10:36 2003
Subject: [Mailman-Developers] Bug in subscribe program
Message-ID: <bqscp9$7hq$1@sea.gmane.org>

Dear all,

I have found a bug which I can reproduce with Mailman 2.1.2 on Debian Woody
(according to the NEWS file, it's still not fixed in Mailman 2.1.3).

When a user enters the subscription web page, enters his data _and_ a
passwort that contains German umlauts (? ? ?), he will get the following
error message:

===
Bug in Mailman version 2.1.2
We're sorry, we hit a bug!

[...]

Traceback:

Traceback (most recent call last):
  File "/var/lib/mailman/scripts/driver", line 87, in run_main
    main()
  File "/usr/lib/mailman/Mailman/Cgi/subscribe.py", line 96, in main
    process_form(mlist, doc, cgidata, language)
  File "/usr/lib/mailman/Mailman/Cgi/subscribe.py", line 176, in
process_form
    mlist.AddMember(userdesc, remote)
  File "/usr/lib/mailman/Mailman/MailList.py", line 806, in AddMember
    cookie = Pending.new(Pending.SUBSCRIPTION, userdesc)
  File "/usr/lib/mailman/Mailman/Pending.py", line 80, in new
    hashfood = str(now) + str(n) + str(content)
  File "/usr/lib/mailman/Mailman/UserDesc.py", line 56, in __repr__
    return '' % (
UnicodeError: ASCII decoding error: ordinal not in range(128)
===

I have posted a copy of this page where you can see all further information
on http://www.mstucki.net/files/misc/mailman-bug.html

Kind regards
- michael


From rodolfo at pilas.net  Tue Dec  9 15:49:50 2003
From: rodolfo at pilas.net (Rodolfo Pilas)
Date: Tue Dec  9 15:42:30 2003
Subject: [Mailman-Developers] Improvements MM 2.1.3
Message-ID: <1071002990.653.27.camel@claudia>

I have just installed Mailman 2.1.3 and see the following problems:

1) Explanation with the refuse message.
When a moderator refuse a message and write an explanation to the sender
all works ok.  However if the moderator send a copy of the message to
all moderators, the others do not receive the explanation, they receive
the message only.   Perhaps the same message sent to sender (with the
explanation) would have to be sent to the moderators team.

2) Name and addres at subscriber list view
The subscriber list view list addresses only.  It would be very usefull
to list the address followed by the NAME of each subscriber.


Of course, MM is the best mailserver. You have made an excellent work!


-- 
 Rodolfo Pilas              Quien los puso a estos tipos donde estan,
 rodolfo@pilas.net          Quien los deja seguir en su lugar,
 http://rodolfo.pilas.net   Quien los baja ahora de su altar,
 Yahoo ID: ysidorito        Quien les paga para que hagan lo que haran
 ICQ: 17461636              -=# Apocalipsis Now % Cuarteto de Nos #=-
      
GnuPG Public Key: gpg --keyserver www.keyserver.net --recv-key 57153363 
Key Fingerprint  =>  DAAE 3246 3F7D A420 B7A0  48A5 D120 C773 5715 3363
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada
	digitalmente
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20031209/353fecb0/attachment.bin
From aaron.bennett at olin.edu  Fri Dec 12 16:24:19 2003
From: aaron.bennett at olin.edu (Aaron Bennett)
Date: Sat Dec 13 17:47:24 2003
Subject: [Mailman-Developers] list pickle details
Message-ID: <3FDA3203.1020101@olin.edu>

Hi,

I'm working on writing a mailman statistics program -- simple stuff, and 
I'm sure there are better ones out there then the one I'm writing, but 
I'm also teaching myself python at the same time.

My first approach is to unpickle each list's configuration pickle into 
an array of <whatever the heck they are>.  Does anyone have either a 
concise explanation of what's in each list object when it gets 
unpickled, or a link to some documentation about how mailman's internals 
work?  Also appreciated would be pointers as to where in the mailman 
source code I should start my reading.

thanks so much,

and of course I'll release my stats program when it's done if anyone is 
interested in it,

Aaron Bennett

-- 
Aaron Bennett
UNIX Administrator
Franklin W. Olin College of Engineering




From ben at benhall.ca  Fri Dec  5 14:55:57 2003
From: ben at benhall.ca (Ben Hall)
Date: Sat Dec 13 17:47:42 2003
Subject: [Mailman-Developers] Mailman Integration
Message-ID: <Pine.LNX.4.44.0312051431380.7613-100000@gimp.kensington>

Hi all,

We've got some scripts adding a couple of features for our local
installation of Mailman (v2.1.2). The scripts are using Mailman modules
and classes (mostly MailList) directly as opposed to just calling 
mailman/bin scripts.

I'm wondering how much might we expect the interfaces of these classes to
change between releases of Mailman. Or more generally, how 'supported' is
this means of integrating with Mailman?

Thanks,
Ben Hall




From johnson at nmr.mgh.harvard.edu  Wed Dec  3 10:51:32 2003
From: johnson at nmr.mgh.harvard.edu (Chris Johnson)
Date: Sat Dec 13 17:49:15 2003
Subject: [Mailman-Developers] Possible Web interface bug.
Message-ID: <Pine.LNX.4.44.0312031035220.1582-100000@maequeses.nmr.mgh.harvard.edu>

     Hi,

     Sorry to bother the list with this.  I'm on mailman-users but my
posts are mysteriously vanishing into the entropic ether.

     I'm running RH7.3, Mailman 2.1-8.  I've looked at the bug list
but haven't found anything like this.  

     Posts are held for various reasons, in my case size issues, too
big.  I go to the Web interface at 

     http://host/mailman/admindb/listname

for any list.  None of the actions, i.e. Defer, Accept, Reject or
Discard, seem to work.  There are no errors given.  When I Submit All
the same status page comes back in its original form.  The held message is
still there and never has any action applied as far as I can tell.  

    Are there any bugs relating to this?  If not can any body tell me
what I'm doing wrong?  Help would be greatly appreciated as there is a
increasing held backlog I can't free up.  Thank you.

-------------------------------------------------------------------------------
Chris Johnson               |Internet: johnson@nmr.mgh.harvard.edu
Systems Administrator       |Web:      http://www.nmr.mgh.harvard.edu/~johnson
NMR Center                  |Voice:    617.726.0949
Mass. General Hospital      |FAX:      617.726.7422
149 (2301) 13th Street      |"Life is chaos.  Chaos is life.  Control is an
Charlestown, MA., 02129 USA | illusion."  Trance Gemini
-------------------------------------------------------------------------------


From gharris at mail.nixa.k12.mo.us  Fri Dec  5 13:04:49 2003
From: gharris at mail.nixa.k12.mo.us (Greg Harris)
Date: Sat Dec 13 17:49:16 2003
Subject: [Mailman-Developers] Moderation flag change via script
Message-ID: <000601c3bb5a$4638e390$f614a8c0@cotechgh>

Hello all,

I am writing this to the devel group since the general list said it was not
highly technical.  I am currently running mailman-2.1.2 from a RedHat 7.3
RPM, on RedHat 7.3 with Postfix 2.1.

I am creating scripts to automatically create umbrella lists from other
lists using sync_members.  However, I need a way to unset the moderation
flag for users for some imported lists, and leave it at moderated for other
lists.  The problem I am having, is that I see no way to change the
moderation flag of a user from the command line on a particular list.  I
don't really care if I need to run a separate script after the sync_members
or not, just that I am able to set the flag from some sort of script.

Thanks,

Greg Harris

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.547 / Virus Database: 340 - Release Date: 12/2/2003
 


From gharris at mail.nixa.k12.mo.us  Fri Dec  5 16:59:16 2003
From: gharris at mail.nixa.k12.mo.us (Greg Harris)
Date: Sat Dec 13 17:49:18 2003
Subject: [Mailman-Developers] RE: Moderation flag change via script
Message-ID: <001d01c3bb7b$07412ff0$f614a8c0@cotechgh>

Google strikes again.  I was searching for the wrong key words.  Once I
found the correct syntax, I found a script to do exactly what I wanted.
Using the search text of "withlist moderate", I found this link:
http://mail.python.org/pipermail/mailman-developers/2002-February/010563.htm
l with a script for setting mod flags inside.
Thanks to Dan Mick for this post.

Thanks,

Greg Harris

-----Original Message-----
From: Greg Harris [mailto:gharris@mail.nixa.k12.mo.us] 
Sent: Friday, December 05, 2003 12:05 PM
To: 'mailman-developers@python.org'
Subject: Moderation flag change via script

Hello all,

I am writing this to the devel group since the general list said it was not
highly technical.  I am currently running mailman-2.1.2 from a RedHat 7.3
RPM, on RedHat 7.3 with Postfix 2.1.

I am creating scripts to automatically create umbrella lists from other
lists using sync_members.  However, I need a way to unset the moderation
flag for users for some imported lists, and leave it at moderated for other
lists.  The problem I am having, is that I see no way to change the
moderation flag of a user from the command line on a particular list.  I
don't really care if I need to run a separate script after the sync_members
or not, just that I am able to set the flag from some sort of script.

Thanks,

Greg Harris

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.547 / Virus Database: 340 - Release Date: 12/2/2003
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.547 / Virus Database: 340 - Release Date: 12/2/2003
 


From ljacobs at mandala-designs.com  Sat Dec  6 16:35:28 2003
From: ljacobs at mandala-designs.com (Len Jacobs)
Date: Sat Dec 13 17:49:20 2003
Subject: [Mailman-Developers] next version of Mailman
Message-ID: <bqti30$5qd$1@sea.gmane.org>

Is there any definite schedule for the delivery of the 2.1.4 version of 
Mailman? Another December upgrade possible?



From scott at villinski.com  Thu Dec 11 18:20:16 2003
From: scott at villinski.com (Scott C. Villinski)
Date: Sat Dec 13 17:49:21 2003
Subject: [Mailman-Developers] How to creating new cgi-bin scripts
Message-ID: <3FD8FBB0.1080202@villinski.com>

I've looked (in the places that I think I should) to find an answer.  On 
my Mailman 2.1.3 server, I want to create a copy of the roster.py file 
but instead have it return an XML document.  I copied the roster.py file 
to: xml-roster.py (in $prefix/Mailman/Cgi).  What do I need to do to 
make it compile and end up in the $prefix/cgi-bin directory?  I 
restarted mailman on my server.  Are the scripts in the cgi-bin 
directory hardcoded somehow?  Any pointers would be great.  Also if this 
  isn't the right list, let me know.  I did post to the mailman-users 
list, but got no bites.

Thanks,

Scott

From hunkims at hotmail.com  Fri Dec 12 17:30:54 2003
From: hunkims at hotmail.com (Sung Kim)
Date: Sat Dec 13 17:49:23 2003
Subject: [Mailman-Developers] Mailman Virtualhosting
Message-ID: <LAW11-OE24gZr8QopoX00008c7e@hotmail.com>

Hi,

I figured that the list name should be unique across the entire site, even
though the site has hundreds of virtual domains: 

The primary problem with all this is that list names must be unique across
the entire site. For example, say you run mysite1.com and mysite2.com and
these are virtually hosted. You cannot have two lists, called
mylist@mysite1.com and mylist@mysite2.com. The only choice you have is to
run two completely separate Mailman installations, each hosting just one of
those domains. This sucks for ISPs? hosting tens or hundreds (or more!)
virtual domains.
(http://zope.org/Members/bwarsaw/MailmanDesignNotes/VirtualHosting)

If this is true, do we have a plan to develop the *real* virtual hosting
function in Mailman:

 mylist@mysite1.com
 mylist@mysite2.com

while mysite1 and mysite2 are actually the same machine. 

--
Sung Kim

From rcpt-mailman-developers.AT.python.org at jankratochvil.net  Sat Dec 13 04:52:29 2003
From: rcpt-mailman-developers.AT.python.org at jankratochvil.net (Jan Kratochvil)
Date: Sat Dec 13 17:49:25 2003
Subject: [Mailman-Developers] List-Id header special ','
Message-ID: <20031213095224.GA614@exuhome.dyn.jankratochvil.net>

Hi,

Mailman currently permits any list 'description' string. It is later inserted
to 'List-Id' header such as:
	List-Id: Patches for autoconf, the GNU build system <autoconf-patches.gnu.org>

This header does not comply with RFC2919 and RFC822/RFC2822 as it uses
a forbidden special ','. 'description' is allowed to be only 'phrase' of RFC822.

It would be needed to quote it:
	List-Id: "Patches for autoconf, the GNU build system" <autoconf-patches.gnu.org>

Please either forbid 'special' characters such as ',' or quote the header
if such offending character is found.



Regards,
Lace

From somuchfun at atlantismail.com  Mon Dec  8 19:25:09 2003
From: somuchfun at atlantismail.com (Somuchfun)
Date: Sat Dec 13 17:50:31 2003
Subject: [Mailman-Developers] (no subject)
Message-ID: <00251993807973@smtp.westbay.net>

Hello,
Is there a way to restrict mailman lists to a certain amount of users?
What I am missing is a way to restrict each list to a maximum amount of
members on a site basis.
Any ideas?

Thanks!


From barry at python.org  Sat Dec 13 17:53:57 2003
From: barry at python.org (Barry Warsaw)
Date: Sat Dec 13 17:54:03 2003
Subject: [Mailman-Developers] Moderation flag change via script
In-Reply-To: <000601c3bb5a$4638e390$f614a8c0@cotechgh>
References: <000601c3bb5a$4638e390$f614a8c0@cotechgh>
Message-ID: <1071356036.29215.24.camel@anthem>

On Fri, 2003-12-05 at 13:04, Greg Harris wrote:

> I am writing this to the devel group since the general list said it was not
> highly technical.  I am currently running mailman-2.1.2 from a RedHat 7.3
> RPM, on RedHat 7.3 with Postfix 2.1.
> 
> I am creating scripts to automatically create umbrella lists from other
> lists using sync_members.  However, I need a way to unset the moderation
> flag for users for some imported lists, and leave it at moderated for other
> lists.  The problem I am having, is that I see no way to change the
> moderation flag of a user from the command line on a particular list.  I
> don't really care if I need to run a separate script after the sync_members
> or not, just that I am able to set the flag from some sort of script.

There currently isn't a script to do this, but it probably wouldn't be
too hard to write if you knew a little Python.  You could either write
it as a full-fledged command line script, or as a bin/withlist
scriptlet.

Contributions are welcome!
-Barry



From barry at python.org  Sat Dec 13 17:55:40 2003
From: barry at python.org (Barry Warsaw)
Date: Sat Dec 13 17:55:47 2003
Subject: [Mailman-Developers] Mailman Integration
In-Reply-To: <Pine.LNX.4.44.0312051431380.7613-100000@gimp.kensington>
References: <Pine.LNX.4.44.0312051431380.7613-100000@gimp.kensington>
Message-ID: <1071356140.29215.27.camel@anthem>

On Fri, 2003-12-05 at 14:55, Ben Hall wrote:

> We've got some scripts adding a couple of features for our local
> installation of Mailman (v2.1.2). The scripts are using Mailman modules
> and classes (mostly MailList) directly as opposed to just calling 
> mailman/bin scripts.
> 
> I'm wondering how much might we expect the interfaces of these classes to
> change between releases of Mailman. Or more generally, how 'supported' is
> this means of integrating with Mailman?

I think that's a fine way to go, and there is very little chance any of
those interfaces will change for the Mailman 2.1.x line.  

I'm still on the fence as to whether the next major version will be 2.2
or 3.0.  For a version 2.2 you can expect some, but not major changes. 
For 3.0 you can expect everything to be rewritten from scratch :).

-Barry



From barry at python.org  Sat Dec 13 18:02:43 2003
From: barry at python.org (Barry Warsaw)
Date: Sat Dec 13 18:02:52 2003
Subject: [Mailman-Developers] Bug in subscribe program
In-Reply-To: <bqscp9$7hq$1@sea.gmane.org>
References: <bqscp9$7hq$1@sea.gmane.org>
Message-ID: <1071356563.29215.29.camel@anthem>

On Sat, 2003-12-06 at 05:58, Michael Stucki wrote:

> I have found a bug which I can reproduce with Mailman 2.1.2 on Debian Woody
> (according to the NEWS file, it's still not fixed in Mailman 2.1.3).
> 
> When a user enters the subscription web page, enters his data _and_ a
> passwort that contains German umlauts (? ? ?), he will get the following
> error message:

I think this specific bug is no longer reproducible in 2.1.3 (or cvs)
because the algorithm for calculating the hashfood has changed.

-Barry



From barry at python.org  Sat Dec 13 18:04:15 2003
From: barry at python.org (Barry Warsaw)
Date: Sat Dec 13 18:04:21 2003
Subject: [Mailman-Developers] next version of Mailman
In-Reply-To: <bqti30$5qd$1@sea.gmane.org>
References: <bqti30$5qd$1@sea.gmane.org>
Message-ID: <1071356655.29215.32.camel@anthem>

On Sat, 2003-12-06 at 16:35, Len Jacobs wrote:
> Is there any definite schedule for the delivery of the 2.1.4 version of 
> Mailman? Another December upgrade possible?

Yes, I'm still planning on 2.1.4 before the end of the year.  My
schedule's been especially slammed lately so I haven't had a chance to
do as much as I wanted for this release, but I believe it's stable so
whatever the state of the code 23:59:59 31-Dec-2003 EST is likely what
you'll get :)

-Barry



From barry at python.org  Sat Dec 13 18:05:30 2003
From: barry at python.org (Barry Warsaw)
Date: Sat Dec 13 18:05:36 2003
Subject: [Mailman-Developers] (no subject)
In-Reply-To: <00251993807973@smtp.westbay.net>
References: <00251993807973@smtp.westbay.net>
Message-ID: <1071356730.29215.34.camel@anthem>

On Mon, 2003-12-08 at 19:25, Somuchfun wrote:

> Is there a way to restrict mailman lists to a certain amount of users?
> What I am missing is a way to restrict each list to a maximum amount of
> members on a site basis.
> Any ideas?

Not with stock Mailman 2.1.x.

-Barry



From barry at python.org  Sat Dec 13 18:07:48 2003
From: barry at python.org (Barry Warsaw)
Date: Sat Dec 13 18:07:53 2003
Subject: [Mailman-Developers] How to creating new cgi-bin scripts
In-Reply-To: <3FD8FBB0.1080202@villinski.com>
References: <3FD8FBB0.1080202@villinski.com>
Message-ID: <1071356867.29215.36.camel@anthem>

On Thu, 2003-12-11 at 18:20, Scott C. Villinski wrote:
> I've looked (in the places that I think I should) to find an answer.  On 
> my Mailman 2.1.3 server, I want to create a copy of the roster.py file 
> but instead have it return an XML document.  I copied the roster.py file 
> to: xml-roster.py (in $prefix/Mailman/Cgi).  What do I need to do to 
> make it compile and end up in the $prefix/cgi-bin directory?  I 
> restarted mailman on my server.  Are the scripts in the cgi-bin 
> directory hardcoded somehow?  Any pointers would be great.  Also if this 
>   isn't the right list, let me know.  I did post to the mailman-users 
> list, but got no bites.

You need to add 'xml-roster' to the CGI_PROGS variable in
src/Makefile.in.  This is because Mailman builds some C wrappers around
the Python cgi scripts (ostensibly for improved security).

-Barry



From barry at python.org  Sat Dec 13 18:15:05 2003
From: barry at python.org (Barry Warsaw)
Date: Sat Dec 13 18:15:11 2003
Subject: [Mailman-Developers] list pickle details
In-Reply-To: <3FDA3203.1020101@olin.edu>
References: <3FDA3203.1020101@olin.edu>
Message-ID: <1071357304.29215.45.camel@anthem>

On Fri, 2003-12-12 at 16:24, Aaron Bennett wrote:

> My first approach is to unpickle each list's configuration pickle into 
> an array of <whatever the heck they are>.  

That's about the best explanation you're gonna get. <wink>

> Does anyone have either a 
> concise explanation of what's in each list object when it gets 
> unpickled, or a link to some documentation about how mailman's internals 
> work?  Also appreciated would be pointers as to where in the mailman 
> source code I should start my reading.

So basically the config.pck file is a pickled Python dictionary.  This
dictionary is essentially the attributes of the MailList object.  So
anywhere you see self.max_message_size or mlist.description, you're
accessing a MailList attribute.  Unfortunately, the actual use and
semantics of these attributes is not documented anywhere.  You're going
to have to grep the source to figure out where and how each attribute is
used, and what it's values consist of.

Well, maybe.  One thing that may help is the output of bin/config_list. 
Use "bin/config_list -o - mylist" to get a dump of most of the
attributes (the ones that you can set through the web interface).  The
preceding comments should give a good explanation of what the attribute
is used for and what it can contain.

-Barry



From barry at python.org  Sat Dec 13 18:25:31 2003
From: barry at python.org (Barry Warsaw)
Date: Sat Dec 13 18:25:37 2003
Subject: [Mailman-Developers] List-Id header special ','
In-Reply-To: <20031213095224.GA614@exuhome.dyn.jankratochvil.net>
References: <20031213095224.GA614@exuhome.dyn.jankratochvil.net>
Message-ID: <1071357931.29215.47.camel@anthem>

On Sat, 2003-12-13 at 04:52, Jan Kratochvil wrote:
> Hi,
> 
> Mailman currently permits any list 'description' string. It is later inserted
> to 'List-Id' header such as:
> 	List-Id: Patches for autoconf, the GNU build system <autoconf-patches.gnu.org>
> 
> This header does not comply with RFC2919 and RFC822/RFC2822 as it uses
> a forbidden special ','. 'description' is allowed to be only 'phrase' of RFC822.
> 
> It would be needed to quote it:
> 	List-Id: "Patches for autoconf, the GNU build system" <autoconf-patches.gnu.org>
> 
> Please either forbid 'special' characters such as ',' or quote the header
> if such offending character is found.

Fixed for 2.1.4.

-Barry



From mundaun at gmx.ch  Sat Dec 13 19:53:50 2003
From: mundaun at gmx.ch (Michael Stucki)
Date: Sat Dec 13 19:53:56 2003
Subject: [Mailman-Developers] Re: Bug in subscribe program
References: <bqscp9$7hq$1@sea.gmane.org> <1071356563.29215.29.camel@anthem>
Message-ID: <brgcau$g4n$1@sea.gmane.org>

Barry Warsaw wrote:

> I think this specific bug is no longer reproducible in 2.1.3 (or cvs)
> because the algorithm for calculating the hashfood has changed.

Great! Thank you.

Regards, michael


From tkikuchi at is.kochi-u.ac.jp  Sun Dec 14 19:08:35 2003
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Sun Dec 14 19:08:32 2003
Subject: [Mailman-Developers] Re: [Mailman-checkins]
 mailman/Mailman/Handlers CookHeaders.py, 2.33.2.3, 2.33.2.4
In-Reply-To: <E1AVJ8q-0006nn-00@sc8-pr-cvs1.sourceforge.net>
References: <E1AVJ8q-0006nn-00@sc8-pr-cvs1.sourceforge.net>
Message-ID: <3FDCFB83.3040008@is.kochi-u.ac.jp>

Hi Barry,

I think this one is not necessary if the encoding is non-ascii.
Any special characters should be properly escaped.

bwarsaw@users.sourceforge.net wrote:

> Update of /cvsroot/mailman/mailman/Mailman/Handlers
> In directory sc8-pr-cvs1:/tmp/cvs-serv26065
> 
> Modified Files:
>       Tag: Release_2_1-maint
> 	CookHeaders.py 
> Log Message:
> process(): Quote the description when adding it to the List-ID header,
> in case there are any special characters (in the RFC 2822) in the
> description.
> 
> 
> Index: CookHeaders.py
> ===================================================================
> RCS file: /cvsroot/mailman/mailman/Mailman/Handlers/CookHeaders.py,v
> retrieving revision 2.33.2.3
> retrieving revision 2.33.2.4
> diff -u -d -r2.33.2.3 -r2.33.2.4
> --- CookHeaders.py	22 Sep 2003 02:37:51 -0000	2.33.2.3
> +++ CookHeaders.py	13 Dec 2003 23:25:42 -0000	2.33.2.4
> @@ -168,7 +168,7 @@
>      listid = '<%s.%s>' % (mlist.internal_name(), mlist.host_name)
>      if mlist.description:
>          # Make sure description is properly i18n'd
> -        listid_h = uheader(mlist, mlist.description, 'List-Id')
> +        listid_h = uheader(mlist, u'"' + mlist.description + u'"', 'List-Id')
>          listid_h.append(listid, 'us-ascii')
>      else:
>          # For wrapping
> 
> 
> 
> _______________________________________________
> Mailman-checkins mailing list
> Mailman-checkins@python.org
> Unsubscribe: http://mail.python.org/mailman/options/mailman-checkins/tkikuchi%40is.kochi-u.ac.jp
> 
> 

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


From barry at python.org  Mon Dec 15 09:48:20 2003
From: barry at python.org (Barry Warsaw)
Date: Mon Dec 15 09:48:25 2003
Subject: [Mailman-Developers] Re: [Mailman-checkins]
	mailman/Mailman/Handlers CookHeaders.py, 2.33.2.3, 2.33.2.4
In-Reply-To: <3FDCFB83.3040008@is.kochi-u.ac.jp>
References: <E1AVJ8q-0006nn-00@sc8-pr-cvs1.sourceforge.net>
	<3FDCFB83.3040008@is.kochi-u.ac.jp>
Message-ID: <1071499700.970.70.camel@anthem>

On Sun, 2003-12-14 at 19:08, Tokio Kikuchi wrote:

> I think this one is not necessary if the encoding is non-ascii.
> Any special characters should be properly escaped.

But if you look a the way uheader() is used here, it always turns the
description string into a unicode, so Header won't RFC 2047 quote the
string.

-Barry



From tkikuchi at is.kochi-u.ac.jp  Mon Dec 15 19:21:51 2003
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Mon Dec 15 19:21:49 2003
Subject: [Mailman-Developers] Re:
	[Mailman-checkins]	mailman/Mailman/Handlers
	CookHeaders.py, 2.33.2.3, 2.33.2.4
In-Reply-To: <1071499700.970.70.camel@anthem>
References: <E1AVJ8q-0006nn-00@sc8-pr-cvs1.sourceforge.net>	<3FDCFB83.3040008@is.kochi-u.ac.jp>
	<1071499700.970.70.camel@anthem>
Message-ID: <3FDE501F.6010102@is.kochi-u.ac.jp>

Hi,

Test installation at my site gives this error. (Python 2.2.3)
Note that mlist.descriptions is 8bit on with charset euc-jp.


  File "/usr/local/mailman2/Mailman/Handlers/CookHeaders.py", line 171,
in process
    listid_h = uheader(mlist, u'"' + mlist.description + u'"', 'List-Id')
UnicodeError: ASCII decoding error: ordinal not in range(128)

Dec 16 09:13:22 2003 (81898) SHUNTING:
1071533601.574297+1ee7c12b04ff84333636fc5
5d1d0e4a7d916797e


Barry Warsaw wrote:
> On Sun, 2003-12-14 at 19:08, Tokio Kikuchi wrote:
> 
> 
>>I think this one is not necessary if the encoding is non-ascii.
>>Any special characters should be properly escaped.
> 
> 
> But if you look a the way uheader() is used here, it always turns the
> description string into a unicode, so Header won't RFC 2047 quote the
> string.
> 
> -Barry
> 
> 
> 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> 
> 

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


From barry at python.org  Thu Dec 18 09:58:57 2003
From: barry at python.org (Barry Warsaw)
Date: Thu Dec 18 09:59:03 2003
Subject: [Mailman-Developers] Re:
	[Mailman-checkins]	mailman/Mailman/Handlers CookHeaders.py, 2.33.2.3,
	2.33.2.4
In-Reply-To: <3FDE501F.6010102@is.kochi-u.ac.jp>
References: <E1AVJ8q-0006nn-00@sc8-pr-cvs1.sourceforge.net>
	<3FDCFB83.3040008@is.kochi-u.ac.jp> <1071499700.970.70.camel@anthem>
	<3FDE501F.6010102@is.kochi-u.ac.jp>
Message-ID: <1071759537.26140.0.camel@anthem>

On Mon, 2003-12-15 at 19:21, Tokio Kikuchi wrote:

> Test installation at my site gives this error. (Python 2.2.3)
> Note that mlist.descriptions is 8bit on with charset euc-jp.

I just checked in a change.  Could you please test it?

-Barry



From darsie at gmx.at  Tue Dec 16 17:44:14 2003
From: darsie at gmx.at (Bernhard Kuemel)
Date: Thu Dec 18 10:02:40 2003
Subject: [Mailman-Developers] python is slow
References: <3FB78C1A.5080702@gmx.at> <20031121003627.GJ9121@dust.uchicago.edu>
	<3FC39580.2020605@gmx.at>
	<20276EA2-1F78-11D8-8CA9-000A957C9A50@openinfo.co.uk>
	<3FC3B653.9060608@gmx.at>
	<7A7514A4-1F91-11D8-8CA9-000A957C9A50@openinfo.co.uk>
Message-ID: <3FDF8ABE.3020206@gmx.at>

Richard Barrett wrote:
> On 25 Nov 2003, at 20:06, Bernhard Kuemel wrote:
>> Maybe. However, I don't like python as on our old P60 server it burned 
>> up so much CPU time (15 s/min).
> 
> It would be interesting to see you present convincing evidence that 
> Python runs slower than Perl which you seem happy to rely on.

Eric Steven Raymond says in "The Art of Unix Programming" 
(http://www.faqs.org/docs/artu/index.html) on 
http://www.faqs.org/docs/artu/ch14s04.html :

"Python cannot compete with C or C++ on raw execution speed 
(though using a mixed-language strategy on today's fast 
processors probably makes that relatively unimportant). In fact 
it's generally thought to be the least efficient and slowest of 
the major scripting languages, a price it pays for runtime type 
polymorphism. Beware of rejecting Python on these grounds, 
however; most applications do not actually need better 
performance than Python offers, and even those that appear to are 
generally limited by external latencies such as network or disk 
waits that entirely swamp the effects of Python's interpretive 
overhead. Also, by way of compensation, Python is exceptionally 
easy to combine with C, so performance-critical Python modules 
can be readily translated into that language for substantial 
speed gains."

Bernhard

-- 
Webspace; Low end Serverhousing ab 15 e, etc.: http://www.bksys.at
Linux Admin/Programmierer: http://bksys.at/bernhard/services.html


From tech at point0.net  Mon Dec 15 15:51:29 2003
From: tech at point0.net (Ken Stillson)
Date: Thu Dec 18 10:02:56 2003
Subject: [Mailman-Developers] AOL 9.0 categorizing mailman verification
	messages as SPAM
Message-ID: <Pine.LNX.4.44.0312151541340.10300-100000@dot.point0.net>


  Hey folks,

  I just got off the phone with someone in the postmaster group at AOL...

  I was calling them because recently all the subscription verification
  messages being generated from my lists are getting categorized a SPAM for
  AOL 9.0 users, and most of them aren't thinking to check their SPAM
  folders.

  The fellow mentioned that long random-looking alpha-numeric strings in the
  subject line are one of the things that triggers their filter.

  Are folks here aware of this issue?  AOL suggested moving the verification
  "cookie" from the subject line to the contents of the message

  Realizing that mailman can't be specialized to meet every quirk of every
  ISP;  but AOL isn't just any ISP, for me anyway, some 80% of my
  subscription requests for my several dozen lists come from there.

  Any thoughts?  Thanks!

    - Ken Stillson
      System Administrator
      Point0.net



From spacey-mailman at lenin.nu  Thu Dec 18 10:37:28 2003
From: spacey-mailman at lenin.nu (Peter C. Norton)
Date: Thu Dec 18 10:37:32 2003
Subject: [Mailman-Developers] python is slow
In-Reply-To: <3FDF8ABE.3020206@gmx.at>
References: <3FB78C1A.5080702@gmx.at> <20031121003627.GJ9121@dust.uchicago.edu>
	<3FC39580.2020605@gmx.at>
	<20276EA2-1F78-11D8-8CA9-000A957C9A50@openinfo.co.uk>
	<3FC3B653.9060608@gmx.at>
	<7A7514A4-1F91-11D8-8CA9-000A957C9A50@openinfo.co.uk>
	<3FDF8ABE.3020206@gmx.at>
Message-ID: <20031218153728.GW23011@lenin.nu>

On Tue, Dec 16, 2003 at 11:44:14PM +0100, Bernhard Kuemel wrote:
> Eric Steven Raymond says in "The Art of Unix Programming" 
> 
> "Python cannot compete with C or C++ on raw execution speed 
> (though using a mixed-language strategy on today's fast 
> processors probably makes that relatively unimportant). 

Uhh... duh?  There isn't a scripting language out there that's faster
than C (I mean, there are things that scripting languages can *make*
faster, like preventing ppl from doing stupid sorts by only putting in
well-optimized sort algo's but that's not what most ppl mean by
"speed").  I can't believe ESR wrote that for python and not just for
scripting languages in general.

> In fact 
> it's generally thought to be the least efficient and slowest of 
> the major scripting languages, a price it pays for runtime type 
> polymorphism. 

Really?  I never thought that python was slower than, say, tcl prior
to 8.x.  I thought that the general concensus is that python and perl
are about neck-and-neck for the fastest possible interpreter.

But in short you're taking something written for popular consumption
instead of writing a test case in a few languages and seeing how fast
it runs.  That's not helpful at all.

-Peter

-- 
The 5 year plan:
In five years we'll make up another plan.
Or just re-use this one.


From lj at mandala-designs.com  Thu Dec 18 19:41:11 2003
From: lj at mandala-designs.com (ljacobs  )
Date: Thu Dec 18 19:41:25 2003
Subject: [Mailman-Developers] Mailman consultant needed
Message-ID: <200312181941.AA6226032@mandala-designs.com>

If someone who has configured Mailman 2.1.X on FreeBSD and RH Linux with Postfix as the MTA would be interested in an installation and configuration project for Mandala Designs, please contact me.

I am experienced with some aspects of Mailman and have a brick wall with a recent development and problem.

Thanks. 

 
________________________________________________________________
Sent via the WebMessaging system at mandala-designs.com


 
                   

---
[This E-mail scanned for viruses by Declude Virus]


From tkikuchi at is.kochi-u.ac.jp  Thu Dec 18 19:58:56 2003
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Thu Dec 18 19:58:57 2003
Subject: [Mailman-Developers]
	Re:	[Mailman-checkins]	mailman/Mailman/Handlers
	CookHeaders.py, 2.33.2.3,	2.33.2.4
In-Reply-To: <1071759537.26140.0.camel@anthem>
References: <E1AVJ8q-0006nn-00@sc8-pr-cvs1.sourceforge.net>	<3FDCFB83.3040008@is.kochi-u.ac.jp>
	<1071499700.970.70.camel@anthem>	<3FDE501F.6010102@is.kochi-u.ac.jp>
	<1071759537.26140.0.camel@anthem>
Message-ID: <3FE24D50.7060707@is.kochi-u.ac.jp>

Thanks a lot, Barry. Now it's OK with Japanese characters.

Tokio

Barry Warsaw wrote:

> On Mon, 2003-12-15 at 19:21, Tokio Kikuchi wrote:
> 
> 
>>Test installation at my site gives this error. (Python 2.2.3)
>>Note that mlist.descriptions is 8bit on with charset euc-jp.
> 
> 
> I just checked in a change.  Could you please test it?
> 
> -Barry
> 


From barry at python.org  Fri Dec 19 07:50:32 2003
From: barry at python.org (Barry Warsaw)
Date: Fri Dec 19 07:50:38 2003
Subject: [Mailman-Developers]
	Re:	[Mailman-checkins]	mailman/Mailman/Handlers CookHeaders.py,
	2.33.2.3,	2.33.2.4
In-Reply-To: <3FE24D50.7060707@is.kochi-u.ac.jp>
References: <E1AVJ8q-0006nn-00@sc8-pr-cvs1.sourceforge.net>
	<3FDCFB83.3040008@is.kochi-u.ac.jp> <1071499700.970.70.camel@anthem>
	<3FDE501F.6010102@is.kochi-u.ac.jp> <1071759537.26140.0.camel@anthem>
	<3FE24D50.7060707@is.kochi-u.ac.jp>
Message-ID: <1071838232.31232.40.camel@anthem>

On Thu, 2003-12-18 at 19:58, Tokio Kikuchi wrote:
> Thanks a lot, Barry. Now it's OK with Japanese characters.

Yay!

Thanks for testing.
-Barry



From pioppo at ferrara.linux.it  Sat Dec 20 09:03:04 2003
From: pioppo at ferrara.linux.it (Simone Piunno)
Date: Sat Dec 20 08:39:16 2003
Subject: [Mailman-Developers] AOL 9.0 categorizing mailman verification
	messages as SPAM
In-Reply-To: <Pine.LNX.4.44.0312151541340.10300-100000@dot.point0.net>
References: <Pine.LNX.4.44.0312151541340.10300-100000@dot.point0.net>
Message-ID: <200312201503.04514.pioppo@ferrara.linux.it>

On Monday 15 December 2003 21:51, Ken Stillson wrote:

>   The fellow mentioned that long random-looking alpha-numeric strings in
> the subject line are one of the things that triggers their filter.
>   Are folks here aware of this issue?  AOL suggested moving the
> verification "cookie" from the subject line to the contents of the message
>   Realizing that mailman can't be specialized to meet every quirk of every
>   ISP;  but AOL isn't just any ISP, for me anyway, some 80% of my
>   subscription requests for my several dozen lists come from there.
>   Any thoughts?  Thanks!

Here in Italy, AOL it's not just any ISP: I guess 95% of italians don't even 
know that AOL exists or what it is at all.  The remaining 5% probably knows 
AOL because they received spam apparently from an AOL email address ;)  
I can imagine the same holds true almost everywhere outside USA.

I'm against any change to mainstream Mailman screwing up almost all users in 
the world just to workaround problems of one ISP that, even if predominant in 
the USA, still represents a small portion of those users.

But hey, this is free software and you don't have to accept my opinion or 
Barry's or anyone else: the license gives you the freedom to patch your copy 
and implement this workaround on your servers!

Cheers,
  Simone

-- 
Adde parvum parvo magnus acervus erit -- Ovidio


From barry at python.org  Mon Dec 22 11:49:58 2003
From: barry at python.org (Barry Warsaw)
Date: Mon Dec 22 11:50:07 2003
Subject: [Mailman-Developers] SourceForge donations for the GNU Mailman
	project
Message-ID: <1072111797.18828.117.camel@anthem>

SourceForge recently instituted a donation system for projects and
users, whereby you can donate some money to a PayPal account to show
your appreciation for the free and open source projects you use. 
Donations to projects require opt-in from all the project's admins.

Jeremy and I have both opted-in to the donation system for the GNU
Mailman project.  I have set the donations email address to the Python
Software Foundation's PayPal account.  This needn't be set in stone, but
we had to pick an address to turn this on and the PSF seemed like a
reasonable choice.  Note that the Python project is accepting donations
for the PSF as well.

GNU Mailman remains free, in both the monetary and liberty senses of the
word.  I personally feel that the good will, help to others, insights,
patches, bug fixes, and general good community that you already donate
is enough reward.  If you feel like making a monetary contribution as
well, please know that the PSF is a US public charity under section
501(c)(3) of the IRS code.  See

	http://www.python.org/psf

for details.

If you have comments or feedback about our choice for the recipient of
donations, or about whether we should be taking donations at all, please
email me directly.

Cheers, and happy holidays,
-Barry



From les at 2pi.org  Mon Dec 22 14:17:11 2003
From: les at 2pi.org (Les Niles)
Date: Mon Dec 22 14:18:40 2003
Subject: [Mailman-Developers] SourceForge donations for the GNU
	Mailman	project
In-Reply-To: <1072111797.18828.117.camel@anthem> (message from Barry Warsaw on
	Mon, 22 Dec 2003 11:49:58 -0500)
References: <1072111797.18828.117.camel@anthem>
Message-ID: <200312221917.hBMJHBwd002823@grumman.kjsl.com>

On Mon, 22 Dec 2003 11:49:58 -0500 Barry Warsaw <barry@python.org> wrote:
>SourceForge recently instituted a donation system for projects and
>users, whereby you can donate some money to a PayPal account to show
>your appreciation for the free and open source projects you use. 
>Donations to projects require opt-in from all the project's admins.
>...  See
>
>	http://www.python.org/psf
>
>for details.
>
>If you have comments or feedback about our choice for the recipient of
>donations, or about whether we should be taking donations at all, please
>email me directly.

Taking donations is a fine idea.  I'm glad to see there's a
snail-mail address for sending checks, because I won't use PayPal
-- it's not safe enough for my money.  

  -les

From barry at python.org  Wed Dec 24 11:05:00 2003
From: barry at python.org (Barry Warsaw)
Date: Wed Dec 24 11:05:19 2003
Subject: [Mailman-Developers] Re: [Mailman-checkins]
	mailman/messages/fr/LC_MESSAGES mailman.po, 2.64, 2.65
In-Reply-To: <E1AYvrc-0003AV-00@sc8-pr-cvs1.sourceforge.net>
References: <E1AYvrc-0003AV-00@sc8-pr-cvs1.sourceforge.net>
Message-ID: <1072281900.3190.2.camel@anthem>

On Tue, 2003-12-23 at 18:22, p_george@users.sourceforge.net wrote:
> Update of /cvsroot/mailman/mailman/messages/fr/LC_MESSAGES
> In directory sc8-pr-cvs1:/tmp/cvs-serv12117/messages/fr/LC_MESSAGES
> 
> Modified Files:
> 	mailman.po 
> Log Message:
> Christmas updates from p.george

Don't forget to backport these changes to the Release_2_1-maint branch,
or they won't make it into Mailman 2.1.4!

-Barry



From darsie at gmx.at  Thu Dec 18 14:52:24 2003
From: darsie at gmx.at (Bernhard Kuemel)
Date: Fri Dec 26 11:56:11 2003
Subject: [Mailman-Developers] python is slow
References: <DBFA7AE8-318F-11D8-B10A-000393CA8D66@efn.org>
Message-ID: <3FE20578.7060402@gmx.at>

Larry Price wrote:
> That is not evidence, that is an appeal to authority.
> 
> If you wish to present evidence, you would need to drop a tarball
> containing.
> 
> a. a relatively complex test algorithm and data set
> b. implementations thereof in ${language}
> c. a test script which executes and times each implementation
> 
> You would then need to have a large sample of testers run the tests on a 
> wide variety of platforms, and then do a linear regression of the 
> results to see if speed varied independently of the underlying platform.
> 
> and yet it would still not matter.

You name the reasons why I will not produce the 'convincing 
evidence' Richard Barret is interested in. I do however believe 
ESR is called authority rightly and assume he is has sufficient 
knowledge of and communication with experts in the languages he 
writes about so his opinion adds to my experience that python is 
slow. Some complex things are hard to prove so I thought you 
might be interested in the opinion of a neural network trained in 
the subject.

> with few exceptions the problems that people use python to solve are not 
> ones where
> speed is paramount, but rather ones where understanding what's happening 
> and being able to change it quickly is.
> 
> 
> 
> 
> On Tuesday, December 16, 2003, at 02:44  PM, Bernhard Kuemel wrote:
> 
>> Richard Barrett wrote:
>>
>>> On 25 Nov 2003, at 20:06, Bernhard Kuemel wrote:
>>>
>>>> Maybe. However, I don't like python as on our old P60 server it 
>>>> burned up so much CPU time (15 s/min).
>>>
>>> It would be interesting to see you present convincing evidence that 
>>> Python runs slower than Perl which you seem happy to rely on.
>>
>>
>> Eric Steven Raymond says in "The Art of Unix Programming" 
>> (http://www.faqs.org/docs/artu/index.html) on 
>> http://www.faqs.org/docs/artu/ch14s04.html :
>>
>> "Python cannot compete with C or C++ on raw execution speed (though 
>> using a mixed-language strategy on today's fast processors probably 
>> makes that relatively unimportant). In fact it's generally thought to 
>> be the least efficient and slowest of the major scripting languages, a 
>> price it pays for runtime type polymorphism. By.
>> eware of rejecting Python on these grounds, however; most applications 
>> do not actually need better performance than Python offers, and even 
>> those that appear to are generally limited by external latencies such 
>> as network or disk waits that entirely swamp the effects of Python's 
>> interpretive overhead. Also, by way of compensation, Python is 
>> exceptionally easy to combine with C, so performance-critical Python 
>> modules can be readily translated into that language for substantial 
>> speed gains."
>>
>> Bernhard
>>
>> -- 
>> Webspace; Low end Serverhousing ab 15 e, etc.: http://www.bksys.at
>> Linux Admin/Programmierer: http://bksys.at/bernhard/services.html
>>
>>
>> _______________________________________________
>> Mailman-Developers mailing list
>> Mailman-Developers@python.org
>> http://mail.python.org/mailman/listinfo/mailman-developers
>>
>>
> -- 
> "You are the eventuality of an anomaly , which despite my sincerest
> efforts I have been unable to eliminate from  what is otherwise a harmony
> of mathematical precision. " -The Architect
> "Microsoft has resolved this issue. We have put processes in place to
> ensure there is no recurrence of this eventuality." -Microsoft
> 


-- 
Webspace; Low end Serverhousing ab 15 e, etc.: http://www.bksys.at
Linux Admin/Programmierer: http://bksys.at/bernhard/services.html


From rgpg at technologist.com  Thu Dec 25 16:32:30 2003
From: rgpg at technologist.com (Roberto Perez)
Date: Fri Dec 26 11:56:48 2003
Subject: [Mailman-Developers] Password recovery
Message-ID: <5.1.1.5.2.20031225161530.02a44110@mailer.fsu.edu>

Hi,

I hope I can get some insights into this problem.

I've been using Mailman in our university to administer a number of lists, 
and the web interface has worked well so far for us. However, in the recent 
weeks we have learned a spammer has subscribed many of our email accounts 
to his own mailman system (on a server outside the US), and has disabled 
the web interface. This means no one can get a reminder of their passwords 
to unsubscribe via email (since when an administrator subscribes users no 
password is sent).

As it is now, Mailman is being used to keep those accounts "captive" and 
bombard them with unsolicited email. So the purpose of my email is twofold:

** Development:
- I strongly believe now email commands should also include a password 
reminder/recovery feature, so that in cases like ours users can still get 
their passwords and unsubscribe via email. Currently a password can only be 
recovered via the web interface (which a spammer can disable).

- I also think when the administrator enrolls users, the passwords should 
be sent as a default, with no possibility of disabling this feature. This 
would cut down on misuse of Mailman as the one described above.


** Management:
- This is a generic question to all managers: if
- a Mailman list does not offer a web interface to recover a password to 
unsubscribe,
- the manager does not reply to unsubscription messages,
- the bounce utility has been disabled (so sending fake "Returned mail" 
messages does not trigger unsubscription),
- the monthly password reminder has been disabled,
- the Mailman server is outside the US (so reporting to the FCC is useless),
- and the list is being used to bombard subscribers who did not subscribe 
themselves...
...how else could unsubscription be achieved in Mailman? I know that users 
could put filters, but I'd like for the messages to stop instead of having 
to put patches here and there on each user's machine...


Thanks in advance for any pointers/ideas/suggestion you may have.


Roberto Perez
rgpg@technologist.com


From barry at python.org  Fri Dec 26 12:06:00 2003
From: barry at python.org (Barry Warsaw)
Date: Fri Dec 26 12:06:05 2003
Subject: [Mailman-Developers] python is slow
In-Reply-To: <3FE20578.7060402@gmx.at>
References: <DBFA7AE8-318F-11D8-B10A-000393CA8D66@efn.org>
	<3FE20578.7060402@gmx.at>
Message-ID: <1072458360.4458.13.camel@anthem>

On Thu, 2003-12-18 at 14:52, Bernhard Kuemel wrote:

> You name the reasons why I will not produce the 'convincing 
> evidence' Richard Barret is interested in. I do however believe 
> ESR is called authority rightly and assume he is has sufficient 
> knowledge of and communication with experts in the languages he 
> writes about so his opinion adds to my experience that python is 
> slow. Some complex things are hard to prove so I thought you 
> might be interested in the opinion of a neural network trained in 
> the subject.

Saying "Python is slow" is pretty much a value-less statement.  Slower
than what?  Slow when doing what?  Too slow?  Which version of Python?

Besides that, this thread is more appropriate on python-list@python.org
or some other advocacy list.  I firmly believe Python is both fast
enough and the right choice for Mailman, and that's not going to change.

-Barry



From jeffw at chebucto.ns.ca  Fri Dec 26 21:45:54 2003
From: jeffw at chebucto.ns.ca (Jeff Warnica)
Date: Fri Dec 26 21:43:37 2003
Subject: [Mailman-Developers] Password recovery
In-Reply-To: <5.1.1.5.2.20031225161530.02a44110@mailer.fsu.edu>
References: <5.1.1.5.2.20031225161530.02a44110@mailer.fsu.edu>
Message-ID: <1072493154.24146.26.camel@ron>


- If all the SPAM is coming from one server, block the server at the
SMTP level.
- Spammers using Mailman to send out spam is a Spam problem, not a
Mailman problem.
- Spammers might not actually be using Mailman, just forging the
appearance of mail. I think this is far more likely. While all of
spamassassin's "list removal" tests happens to trigger a positive score,
I would not be at all surprised if SA alternatives, or Bayesian filters
would do the opposite.
- Mailman is Open Source. It would be infinitely easier for a Spammer to
remove any/all password recovery code then it would be for the Mailman
developers to expand on it.
- If you do happen to 'crack' this spammers install of Mailman (possibly
by an "inverse trojan": that of "fixing" Mailman) the spammer could
trivially use an alternate mailing list management system. Or just not
upgrade. Or upgrade and 'break' the new version.

To repeat, I find it unlikely that a spammer is actually using Mailman.
It just doesn't  make any sense. Given the design goals/limitations,
while not incompatible with spamming, Mailman a poor choice. There are
vastly superior, and as easy to find (or stumble upon), alternatives. If
the spammer is using Mailman, then they are using a UNIX MTA; all that I
know of have built in alias/list expansion. Why would they tack on what
is an extremely complex alias/list expansion self management system?


On Thu, 2003-12-25 at 17:32, Roberto Perez wrote:
> Hi,
> 
> I hope I can get some insights into this problem.
> 
> I've been using Mailman in our university to administer a number of lists, 
> and the web interface has worked well so far for us. However, in the recent 
> weeks we have learned a spammer has subscribed many of our email accounts 
> to his own mailman system (on a server outside the US), and has disabled 
> the web interface. This means no one can get a reminder of their passwords 
> to unsubscribe via email (since when an administrator subscribes users no 
> password is sent).
> 
> As it is now, Mailman is being used to keep those accounts "captive" and 
> bombard them with unsolicited email. So the purpose of my email is twofold:
> 
> ** Development:
> - I strongly believe now email commands should also include a password 
> reminder/recovery feature, so that in cases like ours users can still get 
> their passwords and unsubscribe via email. Currently a password can only be 
> recovered via the web interface (which a spammer can disable).
> 
> - I also think when the administrator enrolls users, the passwords should 
> be sent as a default, with no possibility of disabling this feature. This 
> would cut down on misuse of Mailman as the one described above.
> 
> 
> ** Management:
> - This is a generic question to all managers: if
> - a Mailman list does not offer a web interface to recover a password to 
> unsubscribe,
> - the manager does not reply to unsubscription messages,
> - the bounce utility has been disabled (so sending fake "Returned mail" 
> messages does not trigger unsubscription),
> - the monthly password reminder has been disabled,
> - the Mailman server is outside the US (so reporting to the FCC is useless),
> - and the list is being used to bombard subscribers who did not subscribe 
> themselves...
> ...how else could unsubscription be achieved in Mailman? I know that users 
> could put filters, but I'd like for the messages to stop instead of having 
> to put patches here and there on each user's machine...
> 
> 
> Thanks in advance for any pointers/ideas/suggestion you may have.
> 
> 
> Roberto Perez
> rgpg@technologist.com
> 
> 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers


From tkikuchi at is.kochi-u.ac.jp  Sun Dec 28 21:32:57 2003
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Sun Dec 28 21:33:10 2003
Subject: [Mailman-Developers] Re: [Mailman-checkins] mailman/misc
 CJKCodecs-1.0.tar.gz, NONE, 1.1.2.1
 .cvsignore, 2.2, 2.2.2.1 Makefile.in, 2.33.2.3,	2.33.2.4 paths.py.in, 2.6,
 2.6.2.1 JapaneseCodecs-1.4.9.tar.gz,	2.1, NONE KoreanCodecs-2.0.5.tar.gz,
 2.1, NONE
In-Reply-To: <E1AZzmd-0006W0-00@sc8-pr-cvs1.sourceforge.net>
References: <E1AZzmd-0006W0-00@sc8-pr-cvs1.sourceforge.net>
Message-ID: <3FEF9259.3030809@is.kochi-u.ac.jp>

Hi Barry,

I made a mistake on this patch.
Hye-Shik Chang's cjkcodecs site has moved from sourceforge to
http://cjkpython.i18n.org/
He has updated his codecs to 1.0.2, so please download and update the
package and change the package description in Makefile.in accordingly.
http://download.berlios.de/cjkpython/cjkcodecs-1.0.2.tar.gz

Sorry for the inconvenience.


bwarsaw@users.sourceforge.net wrote:
> Update of /cvsroot/mailman/mailman/misc
> In directory sc8-pr-cvs1:/tmp/cvs-serv24964/misc
> 
> Modified Files:
>       Tag: Release_2_1-maint
> 	.cvsignore Makefile.in paths.py.in 
> Added Files:
>       Tag: Release_2_1-maint
> 	CJKCodecs-1.0.tar.gz 
> Removed Files:
>       Tag: Release_2_1-maint
> 	JapaneseCodecs-1.4.9.tar.gz KoreanCodecs-2.0.5.tar.gz 
> Log Message:
> TK's patch # 865661 chunk which replaces JapaneseCodecs-1.4.9 and
> KoreanCodecs-2.0.5 with CJKCodecs-1.0.
> 
> 
> --- NEW FILE: CJKCodecs-1.0.tar.gz ---
> (This appears to be a binary file; contents omitted.)
> 
> Index: .cvsignore
> ===================================================================
> RCS file: /cvsroot/mailman/mailman/misc/.cvsignore,v
> retrieving revision 2.2
> retrieving revision 2.2.2.1
> diff -u -d -r2.2 -r2.2.2.1
> --- .cvsignore	17 Aug 2001 23:19:22 -0000	2.2
> +++ .cvsignore	26 Dec 2003 21:46:09 -0000	2.2.2.1
> @@ -1,3 +1,5 @@
>  Makefile
>  paths.py
>  mailman
> +CJKCodecs-1.0
> +email-2.5.4
> 
> Index: Makefile.in
> ===================================================================
> RCS file: /cvsroot/mailman/mailman/misc/Makefile.in,v
> retrieving revision 2.33.2.3
> retrieving revision 2.33.2.4
> diff -u -d -r2.33.2.3 -r2.33.2.4
> --- Makefile.in	1 Dec 2003 00:12:30 -0000	2.33.2.3
> +++ Makefile.in	26 Dec 2003 21:46:09 -0000	2.33.2.4
> @@ -53,10 +53,9 @@
>  PKGDIR= 	$(srcdir)
>  
>  EMAILPKG=	email-2.5.4
> -JACODECSPKG=	JapaneseCodecs-1.4.9
> -KOCODECSPKG=	KoreanCodecs-2.0.5
> +CJKCODECSPKG=	CJKCodecs-1.0
>  
> -PACKAGES= $(EMAILPKG) $(JACODECSPKG) $(KOCODECSPKG)
> +PACKAGES= $(EMAILPKG) $(CJKCODECSPKG)
>  
>  # Modes for directories and executables created by the install
>  # process.  Default to group-writable directories but
> 
> Index: paths.py.in
> ===================================================================
> RCS file: /cvsroot/mailman/mailman/misc/paths.py.in,v
> retrieving revision 2.6
> retrieving revision 2.6.2.1
> diff -u -d -r2.6 -r2.6.2.1
> --- paths.py.in	21 Oct 2002 19:52:05 -0000	2.6
> +++ paths.py.in	26 Dec 2003 21:46:09 -0000	2.6.2.1
> @@ -1,19 +1,19 @@
>  # -*- python -*-
>  
> -# Copyright (C) 1998,1999,2000,2001,2002 by the Free Software Foundation, Inc.
> +# Copyright (C) 1998-2003 by the Free Software Foundation, Inc.
>  #
>  # This program is free software; you can redistribute it and/or
>  # modify it under the terms of the GNU General Public License
>  # as published by the Free Software Foundation; either version 2
>  # of the License, or (at your option) any later version.
> -# 
> +#
>  # This program is distributed in the hope that it will be useful,
>  # but WITHOUT ANY WARRANTY; without even the implied warranty of
>  # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>  # GNU General Public License for more details.
> -# 
> +#
>  # You should have received a copy of the GNU General Public License
> -# along with this program; if not, write to the Free Software 
> +# along with this program; if not, write to the Free Software
>  # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
>  
>  # This file becomes paths.py which is installed in may directories.  By
> @@ -49,12 +49,8 @@
>  sys.path.append(sitedir)
>  
>  
> -# In a normal interactive Python environment, the japanese.pth and korean.pth
> -# files would be imported automatically.  But because we inhibit the importing
> -# of the site module, we need to be explicit about importing these codecs.
> -import japanese
> -# As of KoreanCodecs 2.0.5, you had to do the second import to get the Korean
> -# codecs installed, however leave the first import in there in case an upgrade
> -# changes this.
> -import korean
> -import korean.aliases
> +# We explicitly import CJKCodecs here since we inhibit the importing of the
> +# site module.  As of CJKCodecs-1.0, you have to do the second import.  We may
> +# have to re-activate the first line if an upgrade changes this.
> +#import cjkcodecs
> +import cjkcodecs.aliases
> 
> --- JapaneseCodecs-1.4.9.tar.gz DELETED ---
> 
> --- KoreanCodecs-2.0.5.tar.gz DELETED ---
> 
> 
> 
> _______________________________________________
> Mailman-checkins mailing list
> Mailman-checkins@python.org
> Unsubscribe: http://mail.python.org/mailman/options/mailman-checkins/tkikuchi%40is.kochi-u.ac.jp
> 
> 

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


From tkikuchi at is.kochi-u.ac.jp  Mon Dec 29 03:26:05 2003
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Mon Dec 29 03:26:19 2003
Subject: [Mailman-Developers] Re: [Mailman-checkins] mailman/misc
	CJKCodecs-1.0.tar.gz, 
	NONE, 1.1.2.1 .cvsignore, 2.2, 2.2.2.1 Makefile.in, 2.33.2.3,
	2.33.2.4 paths.py.in, 2.6, 2.6.2.1 JapaneseCodecs-1.4.9.tar.gz, 2.1,
	NONE KoreanCodecs-2.0.5.tar.gz, 2.1, NONE
In-Reply-To: <3FEF9259.3030809@is.kochi-u.ac.jp>
References: <E1AZzmd-0006W0-00@sc8-pr-cvs1.sourceforge.net>
	<3FEF9259.3030809@is.kochi-u.ac.jp>
Message-ID: <3FEFE51D.6010205@is.kochi-u.ac.jp>

Sorry again Barry.

We have to keep JapaneseCodecs and KoreanCodecs in the ditribution
and install in the pythonlib directory because email package designate
japanese and korean as prefix of charsets. I will have to study more
on cjkcodecs behavior (looks like japanese part has old bug in earlier
distribution of JapaneseCodecs) so please cancel this checkin.

Tokio

Tokio Kikuchi wrote:

> Hi Barry,
> 
> I made a mistake on this patch.
> Hye-Shik Chang's cjkcodecs site has moved from sourceforge to
> http://cjkpython.i18n.org/
> He has updated his codecs to 1.0.2, so please download and update the
> package and change the package description in Makefile.in accordingly.
> http://download.berlios.de/cjkpython/cjkcodecs-1.0.2.tar.gz
> 
> Sorry for the inconvenience.
> 
> 
> bwarsaw@users.sourceforge.net wrote:
> 
>>Update of /cvsroot/mailman/mailman/misc
>>In directory sc8-pr-cvs1:/tmp/cvs-serv24964/misc
>>
>>Modified Files:
>>      Tag: Release_2_1-maint
>>	.cvsignore Makefile.in paths.py.in 
>>Added Files:
>>      Tag: Release_2_1-maint
>>	CJKCodecs-1.0.tar.gz 
>>Removed Files:
>>      Tag: Release_2_1-maint
>>	JapaneseCodecs-1.4.9.tar.gz KoreanCodecs-2.0.5.tar.gz 
>>Log Message:
>>TK's patch # 865661 chunk which replaces JapaneseCodecs-1.4.9 and
>>KoreanCodecs-2.0.5 with CJKCodecs-1.0.
>>
>>
>>--- NEW FILE: CJKCodecs-1.0.tar.gz ---
>>(This appears to be a binary file; contents omitted.)
>>
>>Index: .cvsignore
>>===================================================================
>>RCS file: /cvsroot/mailman/mailman/misc/.cvsignore,v
>>retrieving revision 2.2
>>retrieving revision 2.2.2.1
>>diff -u -d -r2.2 -r2.2.2.1
>>--- .cvsignore	17 Aug 2001 23:19:22 -0000	2.2
>>+++ .cvsignore	26 Dec 2003 21:46:09 -0000	2.2.2.1
>>@@ -1,3 +1,5 @@
>> Makefile
>> paths.py
>> mailman
>>+CJKCodecs-1.0
>>+email-2.5.4
>>
>>Index: Makefile.in
>>===================================================================
>>RCS file: /cvsroot/mailman/mailman/misc/Makefile.in,v
>>retrieving revision 2.33.2.3
>>retrieving revision 2.33.2.4
>>diff -u -d -r2.33.2.3 -r2.33.2.4
>>--- Makefile.in	1 Dec 2003 00:12:30 -0000	2.33.2.3
>>+++ Makefile.in	26 Dec 2003 21:46:09 -0000	2.33.2.4
>>@@ -53,10 +53,9 @@
>> PKGDIR= 	$(srcdir)
>> 
>> EMAILPKG=	email-2.5.4
>>-JACODECSPKG=	JapaneseCodecs-1.4.9
>>-KOCODECSPKG=	KoreanCodecs-2.0.5
>>+CJKCODECSPKG=	CJKCodecs-1.0
>> 
>>-PACKAGES= $(EMAILPKG) $(JACODECSPKG) $(KOCODECSPKG)
>>+PACKAGES= $(EMAILPKG) $(CJKCODECSPKG)
>> 
>> # Modes for directories and executables created by the install
>> # process.  Default to group-writable directories but
>>
>>Index: paths.py.in
>>===================================================================
>>RCS file: /cvsroot/mailman/mailman/misc/paths.py.in,v
>>retrieving revision 2.6
>>retrieving revision 2.6.2.1
>>diff -u -d -r2.6 -r2.6.2.1
>>--- paths.py.in	21 Oct 2002 19:52:05 -0000	2.6
>>+++ paths.py.in	26 Dec 2003 21:46:09 -0000	2.6.2.1
>>@@ -1,19 +1,19 @@
>> # -*- python -*-
>> 
>>-# Copyright (C) 1998,1999,2000,2001,2002 by the Free Software Foundation, Inc.
>>+# Copyright (C) 1998-2003 by the Free Software Foundation, Inc.
>> #
>> # This program is free software; you can redistribute it and/or
>> # modify it under the terms of the GNU General Public License
>> # as published by the Free Software Foundation; either version 2
>> # of the License, or (at your option) any later version.
>>-# 
>>+#
>> # This program is distributed in the hope that it will be useful,
>> # but WITHOUT ANY WARRANTY; without even the implied warranty of
>> # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> # GNU General Public License for more details.
>>-# 
>>+#
>> # You should have received a copy of the GNU General Public License
>>-# along with this program; if not, write to the Free Software 
>>+# along with this program; if not, write to the Free Software
>> # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
>> 
>> # This file becomes paths.py which is installed in may directories.  By
>>@@ -49,12 +49,8 @@
>> sys.path.append(sitedir)
>> 
>> 
>>-# In a normal interactive Python environment, the japanese.pth and korean.pth
>>-# files would be imported automatically.  But because we inhibit the importing
>>-# of the site module, we need to be explicit about importing these codecs.
>>-import japanese
>>-# As of KoreanCodecs 2.0.5, you had to do the second import to get the Korean
>>-# codecs installed, however leave the first import in there in case an upgrade
>>-# changes this.
>>-import korean
>>-import korean.aliases
>>+# We explicitly import CJKCodecs here since we inhibit the importing of the
>>+# site module.  As of CJKCodecs-1.0, you have to do the second import.  We may
>>+# have to re-activate the first line if an upgrade changes this.
>>+#import cjkcodecs
>>+import cjkcodecs.aliases
>>
>>--- JapaneseCodecs-1.4.9.tar.gz DELETED ---
>>
>>--- KoreanCodecs-2.0.5.tar.gz DELETED ---
>>
>>
>>
>>_______________________________________________
>>Mailman-checkins mailing list
>>Mailman-checkins@python.org
>>Unsubscribe: http://mail.python.org/mailman/options/mailman-checkins/tkikuchi%40is.kochi-u.ac.jp
>>
>>
> 
> 

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


From barry at python.org  Mon Dec 29 08:30:07 2003
From: barry at python.org (Barry Warsaw)
Date: Mon Dec 29 08:30:12 2003
Subject: [Mailman-Developers] Re: [Mailman-checkins] mailman/misc
	CJKCodecs-1.0.tar.gz, NONE, 1.1.2.1 .cvsignore, 2.2, 2.2.2.1 Makefile.in,
	2.33.2.3,	2.33.2.4 paths.py.in, 2.6, 2.6.2.1
	JapaneseCodecs-1.4.9.tar.gz, 2.1, NONE KoreanCodecs-2.0.5.tar.gz, 2.1,
	NONE
In-Reply-To: <3FEF9259.3030809@is.kochi-u.ac.jp>
References: <E1AZzmd-0006W0-00@sc8-pr-cvs1.sourceforge.net>
	<3FEF9259.3030809@is.kochi-u.ac.jp>
Message-ID: <1072704607.1796.16.camel@anthem>

On Sun, 2003-12-28 at 21:32, Tokio Kikuchi wrote:
> Hi Barry,
> 
> I made a mistake on this patch.
> Hye-Shik Chang's cjkcodecs site has moved from sourceforge to
> http://cjkpython.i18n.org/
> He has updated his codecs to 1.0.2, so please download and update the
> package and change the package description in Makefile.in accordingly.
> http://download.berlios.de/cjkpython/cjkcodecs-1.0.2.tar.gz

Will do.

> Sorry for the inconvenience.

No problem!

-Barry



From barry at python.org  Mon Dec 29 08:53:11 2003
From: barry at python.org (Barry Warsaw)
Date: Mon Dec 29 08:53:19 2003
Subject: [Mailman-Developers] Re: [Mailman-checkins] mailman/misc
	CJKCodecs-1.0.tar.gz, NONE, 1.1.2.1 .cvsignore, 2.2, 2.2.2.1 Makefile.in,
	2.33.2.3, 2.33.2.4 paths.py.in, 2.6, 2.6.2.1 JapaneseCodecs-1.4.9.tar.gz,
	2.1, NONE KoreanCodecs-2.0.5.tar.gz, 2.1, NONE
In-Reply-To: <3FEFE51D.6010205@is.kochi-u.ac.jp>
References: <E1AZzmd-0006W0-00@sc8-pr-cvs1.sourceforge.net>
	<3FEF9259.3030809@is.kochi-u.ac.jp> <3FEFE51D.6010205@is.kochi-u.ac.jp>
Message-ID: <1072705990.1796.38.camel@anthem>

[A discussion about replacing JapaneseCodecs and KoreanCodecs in Mailman
2.1.4 with CJKCodecs]

On Mon, 2003-12-29 at 03:26, Tokio Kikuchi wrote:
> Sorry again Barry.
> 
> We have to keep JapaneseCodecs and KoreanCodecs in the ditribution
> and install in the pythonlib directory because email package designate
> japanese and korean as prefix of charsets. I will have to study more
> on cjkcodecs behavior (looks like japanese part has old bug in earlier
> distribution of JapaneseCodecs) so please cancel this checkin.

Oh dang.

The problem is CODEC_MAP in email/Charset.py, right?

Here's a hack for Mailman 2.1.4:

-----japanese.py
from cjkcodecs import euc-jp, iso-2022-jp, shift_jis

-----korean.py
from cjkcodecs import euc-kr, cp949, iso-2022-kr, johab

We add these two files to Mailman's pythonlib, and then the imports in
Charset.py should work correctly.

It would be nice if cjkcodecs provided backwards compatibility. 
Otherwise, we probably want to provide some ourselves in
email/Charset.py.  I'm not sure there's a better way to do this, but
attached is a strawman (untested) patch for email 2.5.5/Python 2.3.4.  

It's too late to get this into Python 2.3.3, but if this is acceptable,
I can check this in for Python 2.3.4, and cut a new email package
tarball for Mailman 2.1.4, forgoing the above hack.

-Barry




-------------- next part --------------
A non-text attachment was scrubbed...
Name: Charset.py.diff
Type: text/x-patch
Size: 2846 bytes
Desc: not available
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20031229/5f477d83/Charset.py.bin
From barry at python.org  Mon Dec 29 09:10:24 2003
From: barry at python.org (Barry Warsaw)
Date: Mon Dec 29 09:10:31 2003
Subject: [Mailman-Developers] Re: [Mailman-checkins] mailman/misc
	CJKCodecs-1.0.tar.gz, NONE, 1.1.2.1 .cvsignore, 2.2, 2.2.2.1 Makefile.in,
	2.33.2.3, 2.33.2.4 paths.py.in, 2.6, 2.6.2.1 JapaneseCodecs-1.4.9.tar.gz,
	2.1, NONE KoreanCodecs-2.0.5.tar.gz, 2.1, NONE
In-Reply-To: <1072705990.1796.38.camel@anthem>
References: <E1AZzmd-0006W0-00@sc8-pr-cvs1.sourceforge.net>
	<3FEF9259.3030809@is.kochi-u.ac.jp> <3FEFE51D.6010205@is.kochi-u.ac.jp>
	<1072705990.1796.38.camel@anthem>
Message-ID: <1072707023.1796.47.camel@anthem>

On Mon, 2003-12-29 at 08:53, Barry Warsaw wrote:

> It would be nice if cjkcodecs provided backwards compatibility. 
> Otherwise, we probably want to provide some ourselves in
> email/Charset.py.  I'm not sure there's a better way to do this, but
> attached is a strawman (untested) patch for email 2.5.5/Python 2.3.4.  

Amend that.  If I understand how all this works correctly, then
importing cjkcodecs.aliases provides direct mapping for all the
charsets.  So since we already have "import cjkcodecs.aliases" in
Mailman's paths.py, we could just delete euc-jp, iso-2022-jp, shift_jis,
euc-kr, iso-2022-kr, ks_c_5601-1987, and johab from CODEC_MAP and be
done with it.

It looks like we didn't need these aliases in CODEC_MAPS even with the
older codec packages, since they define all the aliases as well.

-Barry



From barry at python.org  Mon Dec 29 09:12:11 2003
From: barry at python.org (Barry Warsaw)
Date: Mon Dec 29 09:12:19 2003
Subject: [Mailman-Developers] Re: [Mailman-checkins] mailman/misc
	CJKCodecs-1.0.tar.gz, NONE, 1.1.2.1 .cvsignore, 2.2, 2.2.2.1 Makefile.in,
	2.33.2.3, 2.33.2.4 paths.py.in, 2.6, 2.6.2.1 JapaneseCodecs-1.4.9.tar.gz,
	2.1, NONE KoreanCodecs-2.0.5.tar.gz, 2.1, NONE
In-Reply-To: <1072705990.1796.38.camel@anthem>
References: <E1AZzmd-0006W0-00@sc8-pr-cvs1.sourceforge.net>
	<3FEF9259.3030809@is.kochi-u.ac.jp> <3FEFE51D.6010205@is.kochi-u.ac.jp>
	<1072705990.1796.38.camel@anthem>
Message-ID: <1072707131.1796.50.camel@anthem>

Will this updated patch work?

-Barry


-------------- next part --------------
A non-text attachment was scrubbed...
Name: Charset.py.diff
Type: text/x-patch
Size: 1953 bytes
Desc: not available
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20031229/a6f972a6/Charset.py.bin
From barry at python.org  Mon Dec 29 09:57:03 2003
From: barry at python.org (Barry Warsaw)
Date: Mon Dec 29 09:57:11 2003
Subject: [I18n-sig] Re: [Mailman-Developers] Re: [Mailman-checkins]
	mailman/misc CJKCodecs-1.0.tar.gz, NONE, 1.1.2.1 .cvsignore, 2.2,
	2.2.2.1 Makefile.in, 2.33.2.3, 2.33.2.4 paths.py.in, 2.6, 2.6.2.1
	JapaneseCodecs-1.4.9.tar.gz, 2.1, NONE KoreanCodecs-2.0.5.tar.gz, 2.1,
	NONE
In-Reply-To: <20031229144146.GA836@i18n.org>
References: <E1AZzmd-0006W0-00@sc8-pr-cvs1.sourceforge.net>
	<3FEF9259.3030809@is.kochi-u.ac.jp> <3FEFE51D.6010205@is.kochi-u.ac.jp>
	<1072705990.1796.38.camel@anthem>  <20031229144146.GA836@i18n.org>
Message-ID: <1072709823.1796.69.camel@anthem>

On Mon, 2003-12-29 at 09:41, Hye-Shik Chang wrote:

> There's a bug report by Jason R. Mastaler already:
> 	http://www.python.org/sf/852347

Ah yes, I'd forgotten about that, thanks.  I've followed up to that
tracker item now.

> CJKCodecs already have enough compatibility aliases for consumer
> programs except that uses 'japanese.' or 'korean.' prefix explicitly.
> It has compatibility aliases for ChineseCodecs also.

Cool.  So if the Charset.py.diff patch in the tracker above looks good
to you, I'll commit that as soon as Python's release23-maint branch
freeze is lifted.  Then I'll cut email 2.5.5 and add that to Mailman
2.1.4.

Sound good?

-Barry



From barry at python.org  Mon Dec 29 09:58:26 2003
From: barry at python.org (Barry Warsaw)
Date: Mon Dec 29 09:58:32 2003
Subject: [I18n-sig] Re: [Mailman-Developers] Re: [Mailman-checkins]
	mailman/misc CJKCodecs-1.0.tar.gz, NONE, 1.1.2.1 .cvsignore, 2.2,
	2.2.2.1 Makefile.in, 2.33.2.3, 2.33.2.4 paths.py.in, 2.6, 2.6.2.1
	JapaneseCodecs-1.4.9.tar.gz, 2.1, NONE KoreanCodecs-2.0.5.tar.gz, 2.1,
	NONE
In-Reply-To: <20031229144409.GA1156@i18n.org>
References: <E1AZzmd-0006W0-00@sc8-pr-cvs1.sourceforge.net>
	<3FEF9259.3030809@is.kochi-u.ac.jp> <3FEFE51D.6010205@is.kochi-u.ac.jp>
	<1072705990.1796.38.camel@anthem> <1072707023.1796.47.camel@anthem>
	<20031229144409.GA1156@i18n.org>
Message-ID: <1072709905.1796.73.camel@anthem>

On Mon, 2003-12-29 at 09:44, Hye-Shik Chang wrote:

> > It looks like we didn't need these aliases in CODEC_MAPS even with the
> > older codec packages, since they define all the aliases as well.
> 
> It's true. But except for ChineseCodecs.

Since we didn't have any prefixes except japanese and korean, I don't
think we're in any worse shape for ChineseCodecs.  Right?

-Barry



From my at freexp.de  Sun Dec 28 17:37:00 2003
From: my at freexp.de (Michael Heydekamp)
Date: Mon Dec 29 10:02:13 2003
Subject: [Mailman-Developers] Tweaking Mail->News Gateway
Message-ID: <8-i55Iz$pwB@my.freexp.de>

Hi Mailman developers,

we at freexp.de are setting up Mailman and INN and are trying to get the
Mail<->News facility to work.  We are neither familiar with Mailman nor
with Python, just being poor old Pascal programmers. ;)

I have been in touch with Brad Knowles before and he advised me to ask
here.

We have three mailing lists and three corresponding newsgroups, which
shall be gated bidirectional.  It even works but what is puzzling us is
that in Mail->News direction Mailman always creates an own MsgID.  This
screws up threading by references: If a newsgroup user replies to a
posting that has been gated from the mailing list to the newsgroup, then
- from the perspective of the mailing list users - his references point
to a "wrong" MsgID when they receive this followup posting being gated
from the newsgroup to the mailing list.

I found the respective code in Queue/NewsRunner.py and also read the
explanation why Mailmain is creating own MsgIDs (I'll come back to this
later on).  I changed the code as follows:

----------8<----------
    # Our Message-ID format is <mailman.secs.pid.listname@hostname>
    msgid = msg['message-id']
    hackmsgid = True
    if msgid:
        hackmsgid = False
    #     mo = mcre.search(msgid)
    #     if mo:
    #         lname, hname = mo.group('listname', 'hostname')
    #         if lname == mlist.internal_name() and hname == mlist.host_name:
    #             hackmsgid = False
    if hackmsgid:
        del msg['message-id']
        msg['Message-ID'] = Utils.unique_message_id(mlist)
----------8<----------

It is not really clear to me how Python can know where a conditional
statement such as "if msgid:" ends (just by the indention?), but this
piece seems to work: The MsgID is now being left untouched.

This is question #1: Is this code OK?  I'm also not sure if the variable
'msgid' contains a boolean or a string...?


Now to the more important issues:

I understand that there are two main reasons why Mailman wants to create
an own MsgID upon gating Mail->News, one of them being to avoid loops.

Even after I changed the code as above, I still can't see a loop.  I
first thought Mailman might check the MsgID of a posting upon deciding
whether it should be gated from the newsgroup to the mailing list, but
this is obviously not the case.  I've had a look into cron/gate_news.py
but couldn't figure out exactly how Mailman is taking that decision.

This is question #2: How does Mailman know if the mailing list has
already seen a posting or not?


Anyway, the second and more important reason for creating own MsgIDs
seems to be the issue of an XPost to two (or more) Usenet-gated mailing
lists.

This is indeed a problem and I understand the background.  Thus we'd
like to tweak Mailman in a way that it does the following:


1. Say we have the mailing lists ml-1, ml-2 and ml-3 and the
   corresponding newsgroups ng-1, ng-2 and ng-3.  Now a mail comes in,
   being addressed to ml-1 and ml-2 (which thus should be gated to ng-1
   and ng-2).

   In fact, two physical mails will come in, and obviously Mailman does
   now create two physical postings, one addressed to ng-1, the other
   one addressed to ng-2.  This in fact creates the problem of duplicate
   MsgIDs.

   But what Mailman should do is to create *one* physical posting,
   x-posted to ng-1 and ng-2 ("Newsgroups: ng-1,ng-2").  This would mean
   that upon dealing with the mail to ml-1 it would have to check if the
   addresses in the To: and Cc: headers contain more than one of "our"
   mailing lists and if these mailing lists are being gated to "our"
   Newsgroups.  If so, then an x-posting as described shall be created.

   When Mailman now has to deal with the second mail to ml-2 (with the
   same MsgID) it shall *not* create another posting anymore.

   Can this be accomplished (and if yes, how)?


2. Of course, if a mail does not have a MsgID at all, then Mailman
   should still create its own MsgID.


Any hint will be appreciated (and again, please consider that we are
newbees with regards to Mailman and Python).  Even if we would have to
hardcode some strings (of mailing lists and/or newsgroups) this would be
a better solution than no solution.


        Michael

From perky at i18n.org  Mon Dec 29 09:41:46 2003
From: perky at i18n.org (Hye-Shik Chang)
Date: Mon Dec 29 10:02:15 2003
Subject: [I18n-sig] Re: [Mailman-Developers] Re: [Mailman-checkins]
	mailman/misc CJKCodecs-1.0.tar.gz, NONE, 1.1.2.1 .cvsignore, 2.2,
	2.2.2.1 Makefile.in, 2.33.2.3, 2.33.2.4 paths.py.in, 2.6,
	2.6.2.1 JapaneseCodecs-1.4.9.tar.gz, 2.1,
	NONE KoreanCodecs-2.0.5.tar.gz, 2.1, NONE
In-Reply-To: <1072705990.1796.38.camel@anthem>
References: <E1AZzmd-0006W0-00@sc8-pr-cvs1.sourceforge.net>
	<3FEF9259.3030809@is.kochi-u.ac.jp>
	<3FEFE51D.6010205@is.kochi-u.ac.jp>
	<1072705990.1796.38.camel@anthem>
Message-ID: <20031229144146.GA836@i18n.org>

On Mon, Dec 29, 2003 at 08:53:11AM -0500, Barry Warsaw wrote:
> [A discussion about replacing JapaneseCodecs and KoreanCodecs in Mailman
> 2.1.4 with CJKCodecs]
> 
> On Mon, 2003-12-29 at 03:26, Tokio Kikuchi wrote:
> > Sorry again Barry.
> > 
> > We have to keep JapaneseCodecs and KoreanCodecs in the ditribution
> > and install in the pythonlib directory because email package designate
> > japanese and korean as prefix of charsets. I will have to study more
> > on cjkcodecs behavior (looks like japanese part has old bug in earlier
> > distribution of JapaneseCodecs) so please cancel this checkin.

I just got a mail that describes problems on CJKCodecs' iso-2022-jp
codec from a Japanese user. I'm investigating it and I plan to
release new minor revision that fixes the problems soon. BTW, I
think shift-jis and euc-jp codec of CJKCodecs 1.0.2 is stable and
backward-compatible enough.

> Oh dang.
> 
> The problem is CODEC_MAP in email/Charset.py, right?

There's a bug report by Jason R. Mastaler already:
	http://www.python.org/sf/852347

> Here's a hack for Mailman 2.1.4:
> 
> -----japanese.py
> from cjkcodecs import euc-jp, iso-2022-jp, shift_jis

and iso_2022_jp_1

> -----korean.py
> from cjkcodecs import euc-kr, cp949, iso-2022-kr, johab
> 
> We add these two files to Mailman's pythonlib, and then the imports in
> Charset.py should work correctly.

Yup. it will. :)

> It would be nice if cjkcodecs provided backwards compatibility. 
> Otherwise, we probably want to provide some ourselves in
> email/Charset.py.  I'm not sure there's a better way to do this, but
> attached is a strawman (untested) patch for email 2.5.5/Python 2.3.4.  

CJKCodecs already have enough compatibility aliases for consumer
programs except that uses 'japanese.' or 'korean.' prefix explicitly.
It has compatibility aliases for ChineseCodecs also.


Hye-Shik

From perky at i18n.org  Mon Dec 29 09:44:09 2003
From: perky at i18n.org (Hye-Shik Chang)
Date: Mon Dec 29 10:02:16 2003
Subject: [I18n-sig] Re: [Mailman-Developers] Re: [Mailman-checkins]
	mailman/misc CJKCodecs-1.0.tar.gz, NONE, 1.1.2.1 .cvsignore, 2.2,
	2.2.2.1 Makefile.in, 2.33.2.3, 2.33.2.4 paths.py.in, 2.6,
	2.6.2.1 JapaneseCodecs-1.4.9.tar.gz, 2.1,
	NONE KoreanCodecs-2.0.5.tar.gz, 2.1, NONE
In-Reply-To: <1072707023.1796.47.camel@anthem>
References: <E1AZzmd-0006W0-00@sc8-pr-cvs1.sourceforge.net>
	<3FEF9259.3030809@is.kochi-u.ac.jp>
	<3FEFE51D.6010205@is.kochi-u.ac.jp>
	<1072705990.1796.38.camel@anthem> <1072707023.1796.47.camel@anthem>
Message-ID: <20031229144409.GA1156@i18n.org>

On Mon, Dec 29, 2003 at 09:10:24AM -0500, Barry Warsaw wrote:
> On Mon, 2003-12-29 at 08:53, Barry Warsaw wrote:
> 
> > It would be nice if cjkcodecs provided backwards compatibility. 
> > Otherwise, we probably want to provide some ourselves in
> > email/Charset.py.  I'm not sure there's a better way to do this, but
> > attached is a strawman (untested) patch for email 2.5.5/Python 2.3.4.  
> 
> Amend that.  If I understand how all this works correctly, then
> importing cjkcodecs.aliases provides direct mapping for all the
> charsets.  So since we already have "import cjkcodecs.aliases" in
> Mailman's paths.py, we could just delete euc-jp, iso-2022-jp, shift_jis,
> euc-kr, iso-2022-kr, ks_c_5601-1987, and johab from CODEC_MAP and be
> done with it.
> 
> It looks like we didn't need these aliases in CODEC_MAPS even with the
> older codec packages, since they define all the aliases as well.

It's true. But except for ChineseCodecs.


Hye-Shik

From barry at python.org  Mon Dec 29 10:05:14 2003
From: barry at python.org (Barry Warsaw)
Date: Mon Dec 29 10:05:32 2003
Subject: [I18n-sig] Re: [Mailman-Developers] Re: [Mailman-checkins]
	mailman/misc CJKCodecs-1.0.tar.gz, NONE, 1.1.2.1 .cvsignore, 2.2,
	2.2.2.1 Makefile.in, 2.33.2.3, 2.33.2.4 paths.py.in, 2.6, 2.6.2.1
	JapaneseCodecs-1.4.9.tar.gz, 2.1, NONE KoreanCodecs-2.0.5.tar.gz, 2.1,
	NONE
In-Reply-To: <20031229144146.GA836@i18n.org>
References: <E1AZzmd-0006W0-00@sc8-pr-cvs1.sourceforge.net>
	<3FEF9259.3030809@is.kochi-u.ac.jp> <3FEFE51D.6010205@is.kochi-u.ac.jp>
	<1072705990.1796.38.camel@anthem>  <20031229144146.GA836@i18n.org>
Message-ID: <1072710313.1796.76.camel@anthem>

On Mon, 2003-12-29 at 09:41, Hye-Shik Chang wrote:

> I just got a mail that describes problems on CJKCodecs' iso-2022-jp
> codec from a Japanese user. I'm investigating it and I plan to
> release new minor revision that fixes the problems soon.

Oh yes, please let me know asap when this is ready.  This is the last
issue I need to clear up before I release Mailman 2.1.4, which /will/
happen before the end of this year.  I'd like for that to be ready
tomorrow (Tuesday 30-Dec) if possible.

-Barry



From perky at i18n.org  Mon Dec 29 10:12:44 2003
From: perky at i18n.org (Hye-Shik Chang)
Date: Mon Dec 29 10:12:51 2003
Subject: [I18n-sig] Re: [Mailman-Developers] Re: [Mailman-checkins]
	mailman/misc CJKCodecs-1.0.tar.gz, NONE, 1.1.2.1 .cvsignore, 2.2,
	2.2.2.1 Makefile.in, 2.33.2.3, 2.33.2.4 paths.py.in, 2.6,
	2.6.2.1 JapaneseCodecs-1.4.9.tar.gz, 2.1,
	NONE KoreanCodecs-2.0.5.tar.gz, 2.1, NONE
In-Reply-To: <1072709823.1796.69.camel@anthem>
References: <E1AZzmd-0006W0-00@sc8-pr-cvs1.sourceforge.net>
	<3FEF9259.3030809@is.kochi-u.ac.jp>
	<3FEFE51D.6010205@is.kochi-u.ac.jp>
	<1072705990.1796.38.camel@anthem> <20031229144146.GA836@i18n.org>
	<1072709823.1796.69.camel@anthem>
Message-ID: <20031229151244.GA1646@i18n.org>

On Mon, Dec 29, 2003 at 09:57:03AM -0500, Barry Warsaw wrote:
> On Mon, 2003-12-29 at 09:41, Hye-Shik Chang wrote:
> 
> > There's a bug report by Jason R. Mastaler already:
> > 	http://www.python.org/sf/852347
> 
> Ah yes, I'd forgotten about that, thanks.  I've followed up to that
> tracker item now.
> 
> > CJKCodecs already have enough compatibility aliases for consumer
> > programs except that uses 'japanese.' or 'korean.' prefix explicitly.
> > It has compatibility aliases for ChineseCodecs also.
> 
> Cool.  So if the Charset.py.diff patch in the tracker above looks good
> to you, I'll commit that as soon as Python's release23-maint branch
> freeze is lifted.  Then I'll cut email 2.5.5 and add that to Mailman
> 2.1.4.
> 
> Sound good?
> 

Okay for me. BTW, if no aliases with same key and value is needed,
can't a line below the alises removed together? :

    'utf-8':     'utf-8', 


Thanks!


Hye-Shik

From barry at python.org  Mon Dec 29 10:19:42 2003
From: barry at python.org (Barry Warsaw)
Date: Mon Dec 29 10:19:53 2003
Subject: [I18n-sig] Re: [Mailman-Developers] Re: [Mailman-checkins]
	mailman/misc CJKCodecs-1.0.tar.gz, NONE, 1.1.2.1 .cvsignore, 2.2,
	2.2.2.1 Makefile.in, 2.33.2.3, 2.33.2.4 paths.py.in, 2.6, 2.6.2.1
	JapaneseCodecs-1.4.9.tar.gz, 2.1, NONE KoreanCodecs-2.0.5.tar.gz, 2.1,
	NONE
In-Reply-To: <20031229151244.GA1646@i18n.org>
References: <E1AZzmd-0006W0-00@sc8-pr-cvs1.sourceforge.net>
	<3FEF9259.3030809@is.kochi-u.ac.jp> <3FEFE51D.6010205@is.kochi-u.ac.jp>
	<1072705990.1796.38.camel@anthem> <20031229144146.GA836@i18n.org>
	<1072709823.1796.69.camel@anthem>  <20031229151244.GA1646@i18n.org>
Message-ID: <1072711181.1796.83.camel@anthem>

On Mon, 2003-12-29 at 10:12, Hye-Shik Chang wrote:

> Okay for me. BTW, if no aliases with same key and value is needed,
> can't a line below the alises removed together? :
> 
>     'utf-8':     'utf-8', 

Good catch, thanks!
-Barry



From rousse at ccr.jussieu.fr  Mon Dec 29 10:50:40 2003
From: rousse at ccr.jussieu.fr (Guillaume Rousse)
Date: Mon Dec 29 10:56:36 2003
Subject: [Mailman-Developers] mailman setup
Message-ID: <200312291650.40147.rousse@ccr.jussieu.fr>

Hello.

I'm one of the guy managing the mailman package for mandrake-linux. I've 
currently trying to make setup a bit more standard and FHS compliant. I need 
developpers help however, first to make sure my changes won't cause trouble, 
second as I think some of these change should get merged upstream, as they 
would benefit more people.

The first issue is file location. We are trying to achieve FHS compliance, so 
i had to move things a bit.

I'm using the --with-var-prefix configure option to have variable files 
in /var/lib/mailman and non-variables files in /usr/lib/mailman. That is 
supported by mailman install. 

Then i move logs from /var/lib/mailman/logs to /var/log/mailman through a 
symlink. 

The config file location, however, is still puzzling me. Having a 
configuration file (mm_cfg.py) under /usr is non-standard, as /usr is 
supposed to be read-only. Moreover, it is a pain for us packagers, as we have 
to include everything but this file as normal files, then tag it as config 
file. I'd really think it should be moved in /etc instead, either by me using 
a symlink, but much better by an upstream change.

The second issue are perms. The default install make everything owned by the 
uid/gid determined at configure stage (mail/mail for me), and make all 
directories setgid, even for non-variables files, which is quite really a 
non-standard practice. So i tried to clean it a bit.

I made everything under /usr/lib/mailman owned by root.root, with standard 
perms (644 for files, 755 for directories) except the binaries 
in /usr/lib/mailman/cgi-bin and usr/lib/mailman/mail which are setgid, and 
owned by mail group. I tested, it seems to work.

I also made top-level directory for variable files (/var/lib/mailman) owned by 
root/root with standard 755 perms, but i didn't tried yet further perm 
modifications there, as mailman need write permissions in subdirectories.

You can have a look at the spec file in CVS if you want details 
(http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/SPECS/mailman/mailman.spec). 
Your comments on my changes are welcome, as well as what could get integrated 
into mailman.
-- 
Those who hesitate under fire usually do not end up KIA, MIA or WIA
		-- Murphy's Military Laws n?101

From tkikuchi at is.kochi-u.ac.jp  Mon Dec 29 20:45:50 2003
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Mon Dec 29 20:46:05 2003
Subject: [I18n-sig] Re: [Mailman-Developers] Re:
	[Mailman-checkins]	mailman/misc
	CJKCodecs-1.0.tar.gz, NONE, 1.1.2.1 .cvsignore, 2.2, 2.2.2.1 Makefile.in,
	2.33.2.3, 2.33.2.4 paths.py.in, 2.6, 2.6.2.1 JapaneseCodecs-1.4.9.tar.gz,
	2.1,	NONE KoreanCodecs-2.0.5.tar.gz, 2.1, NONE
In-Reply-To: <20031229144146.GA836@i18n.org>
References: <E1AZzmd-0006W0-00@sc8-pr-cvs1.sourceforge.net>	<3FEF9259.3030809@is.kochi-u.ac.jp>	<3FEFE51D.6010205@is.kochi-u.ac.jp>	<1072705990.1796.38.camel@anthem>
	<20031229144146.GA836@i18n.org>
Message-ID: <3FF0D8CE.5010701@is.kochi-u.ac.jp>

Hi, All.

>>Oh dang.
>>
>>The problem is CODEC_MAP in email/Charset.py, right?
> 
> 
> There's a bug report by Jason R. Mastaler already:
> 	http://www.python.org/sf/852347
> 
> 
>>Here's a hack for Mailman 2.1.4:
>>
>>-----japanese.py
>>from cjkcodecs import euc-jp, iso-2022-jp, shift_jis
> 

This will not do. (Syntax error!)

My fault is that I have separately installed both JapaneseCodecs
and cjkcodecs in the python site-packages area. Looks like mailman
has looked the site-package codecs before mailman/pytholib codecs.

Since we can get rid of the aliases in Charset.py, woud it not be better
to leave the package installation to the indivisual site owners?

Some Japanese users looks like to prefer JapaneseCodecs than cjkcodecs
and some even prefer using one which override special characters like
full-width roman numerics.

Barry, I again suggest cancelling this commit for cjkcodecs altogether
in the meantime of releasing 2.1.4.

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


From barry at python.org  Mon Dec 29 23:00:50 2003
From: barry at python.org (Barry Warsaw)
Date: Mon Dec 29 23:01:00 2003
Subject: [I18n-sig] Re: [Mailman-Developers] Re:
	[Mailman-checkins]	mailman/misc CJKCodecs-1.0.tar.gz, NONE, 1.1.2.1
	.cvsignore, 2.2, 2.2.2.1 Makefile.in, 2.33.2.3, 2.33.2.4 paths.py.in,
	2.6, 
	2.6.2.1 JapaneseCodecs-1.4.9.tar.gz, 2.1, NONE KoreanCodecs-2.0.5.tar.gz,
	2.1, NONE
In-Reply-To: <3FF0D8CE.5010701@is.kochi-u.ac.jp>
References: <E1AZzmd-0006W0-00@sc8-pr-cvs1.sourceforge.net>
	<3FEF9259.3030809@is.kochi-u.ac.jp>	<3FEFE51D.6010205@is.kochi-u.ac.jp>
	<1072705990.1796.38.camel@anthem> <20031229144146.GA836@i18n.org>
	<3FF0D8CE.5010701@is.kochi-u.ac.jp>
Message-ID: <1072756849.9216.15.camel@anthem>

On Mon, 2003-12-29 at 20:45, Tokio Kikuchi wrote:

> >>-----japanese.py
> >>from cjkcodecs import euc-jp, iso-2022-jp, shift_jis
> > 
> 
> This will not do. (Syntax error!)

I noticed that. ;)  Change the dashes to underscores.

> My fault is that I have separately installed both JapaneseCodecs
> and cjkcodecs in the python site-packages area. Looks like mailman
> has looked the site-package codecs before mailman/pytholib codecs.

Hmm, it shouldn't.  Mailman /should/ be set up to look in pythonlib
first.

> Since we can get rid of the aliases in Charset.py, woud it not be better
> to leave the package installation to the indivisual site owners?

Perhaps, but 1) I think Mailman should come with batteries included and
be easy to install, 2) I don't want to rely on having to install these
packages in the system's site-packages directory because that affects
all users of Python on that system.

> Some Japanese users looks like to prefer JapaneseCodecs than cjkcodecs
> and some even prefer using one which override special characters like
> full-width roman numerics.

Hmm.  I have to defer to you on this.  In general though, it's a shame
there has to be more than one codec package for Japanese.  Also, is
JapaneseCodecs still being developed?

> Barry, I again suggest cancelling this commit for cjkcodecs altogether
> in the meantime of releasing 2.1.4.

Looks like we'll have to.  The other problem is that I can't make the
necessary changes to the email package until the Python 2.3 branch is
freed up and it doesn't look that that will happen in time.  I don't
want to include an unreleased version of the email package with Mailman
2.1.4.

So we'll stick with the status quo for Mailman 2.1.4.  It would really
be nice if Python 2.4 included the Asian codecs by default.

-Barry



From barry at python.org  Mon Dec 29 23:35:04 2003
From: barry at python.org (Barry Warsaw)
Date: Mon Dec 29 23:35:15 2003
Subject: [I18n-sig] Re: [Mailman-Developers] Re:
	[Mailman-checkins]	mailman/misc CJKCodecs-1.0.tar.gz, NONE, 1.1.2.1
	.cvsignore, 2.2, 2.2.2.1 Makefile.in, 2.33.2.3, 2.33.2.4 paths.py.in,
	2.6, 
	2.6.2.1 JapaneseCodecs-1.4.9.tar.gz, 2.1, NONE KoreanCodecs-2.0.5.tar.gz,
	2.1, NONE
In-Reply-To: <1072756849.9216.15.camel@anthem>
References: <E1AZzmd-0006W0-00@sc8-pr-cvs1.sourceforge.net>
	<3FEF9259.3030809@is.kochi-u.ac.jp>	<3FEFE51D.6010205@is.kochi-u.ac.jp>
	<1072705990.1796.38.camel@anthem> <20031229144146.GA836@i18n.org>
	<3FF0D8CE.5010701@is.kochi-u.ac.jp> <1072756849.9216.15.camel@anthem>
Message-ID: <1072758904.9216.24.camel@anthem>

On Mon, 2003-12-29 at 23:00, Barry Warsaw wrote:

> Looks like we'll have to.  The other problem is that I can't make the
> necessary changes to the email package until the Python 2.3 branch is
> freed up and it doesn't look that that will happen in time.  I don't
> want to include an unreleased version of the email package with Mailman
> 2.1.4.

Besides, my patch for Charset.py breaks Python's test suite.  I'm not
yet sure what the right way to fix this is.

http://sourceforge.net/tracker/index.php?func=detail&aid=852347&group_id=5470&atid=105470

-Barry



From barry at python.org  Mon Dec 29 23:48:01 2003
From: barry at python.org (Barry Warsaw)
Date: Mon Dec 29 23:48:14 2003
Subject: [I18n-sig] Re: [Mailman-Developers] Re:
	[Mailman-checkins]	mailman/misc CJKCodecs-1.0.tar.gz, NONE, 1.1.2.1
	.cvsignore, 2.2, 2.2.2.1 Makefile.in, 2.33.2.3, 2.33.2.4 paths.py.in,
	2.6, 
	2.6.2.1 JapaneseCodecs-1.4.9.tar.gz, 2.1, NONE KoreanCodecs-2.0.5.tar.gz,
	2.1, NONE
In-Reply-To: <3FF0D8CE.5010701@is.kochi-u.ac.jp>
References: <E1AZzmd-0006W0-00@sc8-pr-cvs1.sourceforge.net>
	<3FEF9259.3030809@is.kochi-u.ac.jp>	<3FEFE51D.6010205@is.kochi-u.ac.jp>
	<1072705990.1796.38.camel@anthem> <20031229144146.GA836@i18n.org>
	<3FF0D8CE.5010701@is.kochi-u.ac.jp>
Message-ID: <1072759680.9216.28.camel@anthem>

On Mon, 2003-12-29 at 20:45, Tokio Kikuchi wrote:

> Barry, I again suggest cancelling this commit for cjkcodecs altogether
> in the meantime of releasing 2.1.4.

I've done this now in Mailman's cvs (Release_2_1-maint branch).  Please
double check.

-Barry



From perky at i18n.org  Tue Dec 30 01:06:22 2003
From: perky at i18n.org (Hye-Shik Chang)
Date: Tue Dec 30 01:06:29 2003
Subject: [I18n-sig] Re: [Mailman-Developers] Re: [Mailman-checkins]
	mailman/misc CJKCodecs-1.0.tar.gz, NONE, 1.1.2.1 .cvsignore, 2.2,
	2.2.2.1 Makefile.in, 2.33.2.3, 2.33.2.4 paths.py.in, 2.6,
	2.6.2.1 JapaneseCodecs-1.4.9.tar.gz, 2.1,
	NONE KoreanCodecs-2.0.5.tar.gz, 2.1, NONE
In-Reply-To: <1072710313.1796.76.camel@anthem>
References: <E1AZzmd-0006W0-00@sc8-pr-cvs1.sourceforge.net>
	<3FEF9259.3030809@is.kochi-u.ac.jp>
	<3FEFE51D.6010205@is.kochi-u.ac.jp>
	<1072705990.1796.38.camel@anthem> <20031229144146.GA836@i18n.org>
	<1072710313.1796.76.camel@anthem>
Message-ID: <20031230060622.GA21672@i18n.org>

On Mon, Dec 29, 2003 at 10:05:14AM -0500, Barry Warsaw wrote:
> On Mon, 2003-12-29 at 09:41, Hye-Shik Chang wrote:
> 
> > I just got a mail that describes problems on CJKCodecs' iso-2022-jp
> > codec from a Japanese user. I'm investigating it and I plan to
> > release new minor revision that fixes the problems soon.
> 
> Oh yes, please let me know asap when this is ready.  This is the last
> issue I need to clear up before I release Mailman 2.1.4, which /will/
> happen before the end of this year.  I'd like for that to be ready
> tomorrow (Tuesday 30-Dec) if possible.

All the problems on iso-2022-jp* codecs are fixed and a release
candidate for CJKCodecs 1.0.3 is ready. (anyway :-))

http://people.freebsd.org/~perky/cjkcodecs-1.0.3c1.tar.bz2

I'll release 1.0.3 final in a day or two.


Hye-Shik

From tkikuchi at is.kochi-u.ac.jp  Tue Dec 30 07:12:25 2003
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Tue Dec 30 07:12:58 2003
Subject: [Mailman-i18n] Re: [I18n-sig] Re: [Mailman-Developers]
	Re:	[Mailman-checkins]
	mailman/misc CJKCodecs-1.0.tar.gz, NONE, 1.1.2.1	.cvsignore, 2.2,
	2.2.2.1 Makefile.in, 2.33.2.3, 2.33.2.4 paths.py.in, 2.6,
	2.6.2.1 JapaneseCodecs-1.4.9.tar.gz, 
	2.1,	NONE KoreanCodecs-2.0.5.tar.gz, 2.1, NONE
In-Reply-To: <1072758904.9216.24.camel@anthem>
References: <E1AZzmd-0006W0-00@sc8-pr-cvs1.sourceforge.net>	<3FEF9259.3030809@is.kochi-u.ac.jp>	<3FEFE51D.6010205@is.kochi-u.ac.jp>	<1072705990.1796.38.camel@anthem>
	<20031229144146.GA836@i18n.org>	<3FF0D8CE.5010701@is.kochi-u.ac.jp>
	<1072756849.9216.15.camel@anthem> <1072758904.9216.24.camel@anthem>
Message-ID: <3FF16BA9.7090508@is.kochi-u.ac.jp>

I think this patch will fix.

@@ -221,6 +220,8 @@
         # it.
         henc, benc, conv = CHARSETS.get(self.input_charset,
                                         (SHORTEST, BASE64, None))
+        if not conv:
+            conv = self.input_charset
         # Set the attributes, allowing the arguments to override the
default.
         self.header_encoding = henc
         self.body_encoding = benc
@@ -230,7 +231,7 @@
         self.input_codec = CODEC_MAP.get(self.input_charset,
                                          self.input_charset)
         self.output_codec = CODEC_MAP.get(self.output_charset,
-                                            self.input_codec)
+                                            self.output_charset)

     def __str__(self):
         return self.input_charset.lower()

Sorry for folding.


Barry Warsaw wrote:

> On Mon, 2003-12-29 at 23:00, Barry Warsaw wrote:
> 
> 
>>Looks like we'll have to.  The other problem is that I can't make the
>>necessary changes to the email package until the Python 2.3 branch is
>>freed up and it doesn't look that that will happen in time.  I don't
>>want to include an unreleased version of the email package with Mailman
>>2.1.4.
> 
> 
> Besides, my patch for Charset.py breaks Python's test suite.  I'm not
> yet sure what the right way to fix this is.
> 
> http://sourceforge.net/tracker/index.php?func=detail&aid=852347&group_id=5470&atid=105470
> 
> -Barry
> 
> 
> 
> _______________________________________________
> Mailman-i18n mailing list
> Posts: Mailman-i18n@python.org
> Unsubscribe: http://mail.python.org/mailman/options/mailman-i18n/tkikuchi%40is.kochi-u.ac.jp
> 
> 

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


From tkikuchi at is.kochi-u.ac.jp  Tue Dec 30 07:15:09 2003
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Tue Dec 30 07:15:27 2003
Subject: [I18n-sig] Re: [Mailman-Developers]
	Re:	[Mailman-checkins]	mailman/misc
	CJKCodecs-1.0.tar.gz, NONE, 1.1.2.1	.cvsignore, 2.2, 2.2.2.1 Makefile.in,
	2.33.2.3, 2.33.2.4 paths.py.in, 2.6, 2.6.2.1 JapaneseCodecs-1.4.9.tar.gz,
	2.1,	NONE KoreanCodecs-2.0.5.tar.gz,	2.1, NONE
In-Reply-To: <1072759680.9216.28.camel@anthem>
References: <E1AZzmd-0006W0-00@sc8-pr-cvs1.sourceforge.net>	
	<3FEF9259.3030809@is.kochi-u.ac.jp>	<3FEFE51D.6010205@is.kochi-u.ac.jp>	
	<1072705990.1796.38.camel@anthem> <20031229144146.GA836@i18n.org>	
	<3FF0D8CE.5010701@is.kochi-u.ac.jp>
	<1072759680.9216.28.camel@anthem>
Message-ID: <3FF16C4D.1020509@is.kochi-u.ac.jp>

Looks OK. I tested some messages without any codecs in site-package.

--
Tokio

Barry Warsaw wrote:

> On Mon, 2003-12-29 at 20:45, Tokio Kikuchi wrote:
> 
> 
>>Barry, I again suggest cancelling this commit for cjkcodecs altogether
>>in the meantime of releasing 2.1.4.
> 
> 
> I've done this now in Mailman's cvs (Release_2_1-maint branch).  Please
> double check.
> 
> -Barry
> 
> 
> 


From barry at python.org  Tue Dec 30 10:06:00 2003
From: barry at python.org (Barry Warsaw)
Date: Tue Dec 30 10:06:11 2003
Subject: [I18n-sig] Re: [Mailman-Developers]
	Re:	[Mailman-checkins]	mailman/misc CJKCodecs-1.0.tar.gz, NONE,
	1.1.2.1	.cvsignore, 2.2, 2.2.2.1 Makefile.in, 2.33.2.3, 2.33.2.4
	paths.py.in, 2.6,	2.6.2.1 JapaneseCodecs-1.4.9.tar.gz, 2.1,	NONE
	KoreanCodecs-2.0.5.tar.gz,	2.1, NONE
In-Reply-To: <3FF16C4D.1020509@is.kochi-u.ac.jp>
References: <E1AZzmd-0006W0-00@sc8-pr-cvs1.sourceforge.net>
	<3FEF9259.3030809@is.kochi-u.ac.jp>	<3FEFE51D.6010205@is.kochi-u.ac.jp>
	<1072705990.1796.38.camel@anthem> <20031229144146.GA836@i18n.org>
	<3FF0D8CE.5010701@is.kochi-u.ac.jp> <1072759680.9216.28.camel@anthem>
	<3FF16C4D.1020509@is.kochi-u.ac.jp>
Message-ID: <1072796759.9216.48.camel@anthem>

On Tue, 2003-12-30 at 07:15, Tokio Kikuchi wrote:
> Looks OK. I tested some messages without any codecs in site-package.

Great, thanks.  I'll put together 2.1.4rc1 later today.

-Barry



From barry at python.org  Tue Dec 30 10:17:11 2003
From: barry at python.org (Barry Warsaw)
Date: Tue Dec 30 10:17:23 2003
Subject: [Mailman-i18n] Re: [I18n-sig] Re: [Mailman-Developers]
	Re:	[Mailman-checkins] mailman/misc CJKCodecs-1.0.tar.gz, NONE,
	1.1.2.1	.cvsignore, 2.2, 2.2.2.1 Makefile.in, 2.33.2.3, 2.33.2.4
	paths.py.in, 2.6, 2.6.2.1 JapaneseCodecs-1.4.9.tar.gz,  2.1,	NONE
	KoreanCodecs-2.0.5.tar.gz, 2.1, NONE
In-Reply-To: <3FF16BA9.7090508@is.kochi-u.ac.jp>
References: <E1AZzmd-0006W0-00@sc8-pr-cvs1.sourceforge.net>
	<3FEF9259.3030809@is.kochi-u.ac.jp>	<3FEFE51D.6010205@is.kochi-u.ac.jp>
	<1072705990.1796.38.camel@anthem> <20031229144146.GA836@i18n.org>
	<3FF0D8CE.5010701@is.kochi-u.ac.jp> <1072756849.9216.15.camel@anthem>
	<1072758904.9216.24.camel@anthem> <3FF16BA9.7090508@is.kochi-u.ac.jp>
Message-ID: <1072797430.9216.50.camel@anthem>

On Tue, 2003-12-30 at 07:12, Tokio Kikuchi wrote:
> I think this patch will fix.

Works for me, thanks.  I've updated the tracker item.

-Barry



From barry at python.org  Tue Dec 30 10:23:08 2003
From: barry at python.org (Barry Warsaw)
Date: Tue Dec 30 10:23:24 2003
Subject: [Email-SIG] Re: [I18n-sig] Re: [Mailman-Developers] Re:
	[Mailman-checkins] mailman/misc CJKCodecs-1.0.tar.gz, NONE, 1.1.2.1
	.cvsignore, 2.2, 2.2.2.1 Makefile.in, 2.33.2.3, 2.33.2.4 paths.py.in,
	2.6, 
	2.6.2.1 JapaneseCodecs-1.4.9.tar.gz, 2.1, NONE KoreanCodecs-2.0.5.tar.gz,
	2.1, NONE
In-Reply-To: <200312301310.hBUDAHOC027873@localhost.localdomain>
References: <200312301310.hBUDAHOC027873@localhost.localdomain>
Message-ID: <1072797788.9216.57.camel@anthem>

On Tue, 2003-12-30 at 08:10, Anthony Baxter wrote:

> In any case, the 2.3 branch is in feature freeze now (has been for
> quite some time) so it's not likely that this sort of new functionality
> is acceptable on the 2.3 branch.
> 
> Anthony (wearing the harsh release manager hat).

I know that the branch is current frozen waiting for Jack's thaw once
the Mac version of 2.3.3 is finished.  So there's no way this will make
it into the tree before the end of the year, which is my own
self-imposed deadline for Mailman 2.1.4.  No matter; I've reverted the
change in Mailman so we won't be shipping CJKCodecs.

But I do still think this is an appropriate patch for Python 2.3.x,
since it really isn't a new feature.  This change should be appropriate
whether you continue to use the old (and unsupported) Korean and Chinese
codecs, with the alternative (and supported) Japanese codec, or whether
you decide to use the combined CJKCodecs package.  At its heart the
patch actually removes unnecessary dependencies on the separate Asian
codec packages.  Since they all provide aliases, this will make the
Charset.py file independent of the codec package being used.

As soon as Jack thaws the release23-maint branch, I think this patch
should go in.  I intend to apply it to the head for 2.4 now that the
last regression has been fixed.

-Barry



From anthony at interlink.com.au  Tue Dec 30 08:10:17 2003
From: anthony at interlink.com.au (Anthony Baxter)
Date: Tue Dec 30 10:43:29 2003
Subject: [Email-SIG] Re: [I18n-sig] Re: [Mailman-Developers] Re:
	[Mailman-checkins] mailman/misc CJKCodecs-1.0.tar.gz, NONE,
	1.1.2.1 .cvsignore, 2.2, 2.2.2.1 Makefile.in, 2.33.2.3,
	2.33.2.4 paths.py.in, 2.6, 2.6.2.1 JapaneseCodecs-1.4.9.tar.gz,
	2.1, NONE KoreanCodecs-2.0.5.tar.gz, 2.1, NONE 
In-Reply-To: <1072756849.9216.15.camel@anthem> 
Message-ID: <200312301310.hBUDAHOC027873@localhost.localdomain>


>>> Barry Warsaw wrote
> Looks like we'll have to.  The other problem is that I can't make the
> necessary changes to the email package until the Python 2.3 branch is
> freed up and it doesn't look that that will happen in time.  I don't
> want to include an unreleased version of the email package with Mailman
> 2.1.4.

In any case, the 2.3 branch is in feature freeze now (has been for
quite some time) so it's not likely that this sort of new functionality
is acceptable on the 2.3 branch.

Anthony (wearing the harsh release manager hat).

-- 
Anthony Baxter     <anthony@interlink.com.au>   
It's never too late to have a happy childhood.

From anthony at interlink.com.au  Tue Dec 30 22:58:11 2003
From: anthony at interlink.com.au (Anthony Baxter)
Date: Tue Dec 30 22:58:46 2003
Subject: [Email-SIG] Re: [I18n-sig] Re: [Mailman-Developers] Re:
	[Mailman-checkins] mailman/misc CJKCodecs-1.0.tar.gz, NONE,
	1.1.2.1 .cvsignore, 2.2, 2.2.2.1 Makefile.in, 2.33.2.3,
	2.33.2.4 paths.py.in, 2.6, 2.6.2.1 JapaneseCodecs-1.4.9.tar.gz,
	2.1, NONE KoreanCodecs-2.0.5.tar.gz, 2.1, NONE 
In-Reply-To: <1072797788.9216.57.camel@anthem> 
Message-ID: <200312310358.hBV3wBZn007978@localhost.localdomain>


>>> Barry Warsaw wrote
> But I do still think this is an appropriate patch for Python 2.3.x,
> since it really isn't a new feature.  This change should be appropriate
> whether you continue to use the old (and unsupported) Korean and Chinese
> codecs, with the alternative (and supported) Japanese codec, or whether
> you decide to use the combined CJKCodecs package.  At its heart the
> patch actually removes unnecessary dependencies on the separate Asian
> codec packages.  Since they all provide aliases, this will make the
> Charset.py file independent of the codec package being used.

I guess the deciding thing (for me) is that code written to use Python
2.3.4 (and the new codec work) should work on Python 2.3.x (x<4). I 
really don't want to see another repeat of the 2.2.2 fiasco (where 
code written for 2.2.2 wouldn't work on 2.2.1 or 2.2, because of the
new True/False objects). I've seen far, far too much code that's had
to do

  try:
      True, False
  except:
      True = 1
      False = 0

Anthony

-- 
Anthony Baxter     <anthony@interlink.com.au>   
It's never too late to have a happy childhood.


From Nigel.Metheringham at dev.intechnology.co.uk  Wed Dec 31 08:04:56 2003
From: Nigel.Metheringham at dev.intechnology.co.uk (Nigel Metheringham)
Date: Wed Dec 31 08:05:46 2003
Subject: [Mailman-Developers] Password recovery
In-Reply-To: <5.1.1.5.2.20031225161530.02a44110@mailer.fsu.edu>
References: <5.1.1.5.2.20031225161530.02a44110@mailer.fsu.edu>
Message-ID: <1072875896.11472.4.camel@carrot.localnet>

On Thu, 2003-12-25 at 21:32, Roberto Perez wrote:
> - I strongly believe now email commands should also include a password 
> reminder/recovery feature, so that in cases like ours users can still get 
> their passwords and unsubscribe via email. Currently a password can only be 
> recovered via the web interface (which a spammer can disable).

This is desirable, but not for the reasons you mention.
If the spammer is using Mailman (and I agree with Jeff that this is both
unlikely and that Mailman is just not suited for a spamming role), then
its very likely that none of the standard mailman addresses (ie
list-request etc) actually go into Mailman - why would he want to make
Mailman do more work without benefiting him?   Since you say its not
parsing bounces, its likely all those aliases go straight to /dev/null.

	Nigel.

-- 
Nigel Metheringham <Nigel.Metheringham@dev.intechnology.co.uk>


From barry at python.org  Wed Dec 31 09:01:54 2003
From: barry at python.org (Barry Warsaw)
Date: Wed Dec 31 09:02:03 2003
Subject: [Email-SIG] Re: [I18n-sig] Re: [Mailman-Developers] Re:
	[Mailman-checkins] mailman/misc CJKCodecs-1.0.tar.gz, NONE, 1.1.2.1
	.cvsignore, 2.2, 2.2.2.1 Makefile.in, 2.33.2.3, 2.33.2.4 paths.py.in,
	2.6, 
	2.6.2.1 JapaneseCodecs-1.4.9.tar.gz, 2.1, NONE KoreanCodecs-2.0.5.tar.gz,
	2.1, NONE
In-Reply-To: <200312310358.hBV3wBZn007978@localhost.localdomain>
References: <200312310358.hBV3wBZn007978@localhost.localdomain>
Message-ID: <1072879314.28895.238.camel@anthem>

On Tue, 2003-12-30 at 22:58, Anthony Baxter wrote:
> >>> Barry Warsaw wrote
> > But I do still think this is an appropriate patch for Python 2.3.x,
> > since it really isn't a new feature.  This change should be appropriate
> > whether you continue to use the old (and unsupported) Korean and Chinese
> > codecs, with the alternative (and supported) Japanese codec, or whether
> > you decide to use the combined CJKCodecs package.  At its heart the
> > patch actually removes unnecessary dependencies on the separate Asian
> > codec packages.  Since they all provide aliases, this will make the
> > Charset.py file independent of the codec package being used.
> 
> I guess the deciding thing (for me) is that code written to use Python
> 2.3.4 (and the new codec work) should work on Python 2.3.x (x<4). I 
> really don't want to see another repeat of the 2.2.2 fiasco (where 
> code written for 2.2.2 wouldn't work on 2.2.1 or 2.2, because of the
> new True/False objects). I've seen far, far too much code that's had
> to do
> 
>   try:
>       True, False
>   except:
>       True = 1
>       False = 0

Since I don't actually use the codecs, except in the context of Mailman
and even then I couldn't tell you what all those pretty graphics mean, I
think we have to ultimately defer to the experts.  But I don't /think/
its nearly as bad as this.

This change is useful even if you are using the older codecs and decide
to stick with them.  They define the necessary aliases to make this all
work, so the dependencies on the japanese and korean package names
aren't necessary.

-Barry



From barry at python.org  Wed Dec 31 09:21:14 2003
From: barry at python.org (Barry Warsaw)
Date: Wed Dec 31 09:21:18 2003
Subject: [Mailman-Developers] Mailman 2.1.4 tree freeze in 3 hours
Message-ID: <1072880473.28895.251.camel@anthem>

I'm going to be cutting the 2.1.4 release at noon EST, which is
approximately three hours from now.  If there are any last minute i18n
updates, please get them in now.  No other changes are allowed.

After 12noon EST, no other i18n updates will be allowed either.

Thanks and happy new year to all (including those of you already
partying :).

-Barry



From barry at python.org  Wed Dec 31 10:38:07 2003
From: barry at python.org (Barry Warsaw)
Date: Wed Dec 31 10:38:12 2003
Subject: [Mailman-Developers] Re: [Mailman-checkins]
	mailman/messages/de/LC_MESSAGES mailman.po, 2.75, 2.76
In-Reply-To: <E1Abi9V-0001PE-00@sc8-pr-cvs1.sourceforge.net>
References: <E1Abi9V-0001PE-00@sc8-pr-cvs1.sourceforge.net>
Message-ID: <1072885087.31042.19.camel@anthem>

On Wed, 2003-12-31 at 10:20, pheinlein@users.sourceforge.net wrote:
> Update of /cvsroot/mailman/mailman/messages/de/LC_MESSAGES
> In directory sc8-pr-cvs1:/tmp/cvs-serv5338/messages/de/LC_MESSAGES
> 
> Modified Files:
> 	mailman.po 
> Log Message:
> 
> Last quick fix for 2.1.4

Peer, you really need to make these changes on the Release_2_1-maint
branch tag.  These changes are on the trunk and will /not/ make it into
2.1.4 unless you also commit them to the branch!

I'm also going to log into irc.freenode.net #mailman now in case anybody
wants to chat about stuff.

-Barry



From barry at python.org  Wed Dec 31 13:21:50 2003
From: barry at python.org (Barry A. Warsaw)
Date: Wed Dec 31 13:22:00 2003
Subject: [Mailman-Developers] RELEASED Mailman 2.1.4
Message-ID: <16371.5054.109107.157603@gargle.gargle.HOWL>


I have released Mailman 2.1.4, a bug fix release that also contains
support for four new languages: Catalan, Croatian, Romanian, and
Slovenian.  This release also contains a fix for a cross-site
scripting vulnerability in the 'admin' cgi script (see
CAN-2003-0965).  There is also an expanded ability to filter message
headers, nominally to provide better support when Mailman is used in
conjunction with upstream spam and virus filters.

The full source tarball has been made available from the usual sites.
Sorry, there is no patch available yet, but you should be able to
install Mailman 2.1.4 over your existing 2.1.x installation.  See

    http://sourceforge.net/project/showfiles.php?group_id=103

for links to the downloadable files.  After installing, be sure you
restart your Mailman daemon by doing a "mailmanctl restart".

IMPORTANT: You will want to re-run configure before doing a make install.

See also:

    http://www.list.org
    http://mailman.sf.net
    http://www.gnu.org/software/mailman

Enjoy, and have a Happy New Year.
-Barry

-------------------- snip snip --------------------
2.1.4 (31-Dec-2003)

    - Close some cross-site scripting vulnerabilities in the admin pages
      (CAN-2003-0965).

    - New languages: Catalan, Croatian, Romanian, Slovenian.

    - New mm_cfg.py/Defaults.py variable PUBLIC_MBOX which allows the site
      administrator to disable public access to all the raw list mbox files
      (this is not a per-list configuration).

    - Expanded header filter rules under Privacy -> Spam Filters.  Now you can
      specify regular expression matches against any header, with specific
      actions tied to those matches.

    - Rework the SMTP error handling in SMTPDirect.py to avoid scoring bounces
      for all recipients when a permanent error code is returned by the mail
      server (e.g. because of content restrictions).

    - Promoted SYNC_AFTER_WRITE to a Default.py/mm_cfg.py variable and
      make it control syncing on the config.pck file.  Also, we always flush
      and sync message files.

    - Reduce archive bloat by not storing the HTML body of Article objects in
      the Pipermail database.  A new script bin/rb-archfix was added to clean
      up older archives.

    - Proper RFC quoting for List-ID descriptions.

    - PKGDIR can be passed to the make command in order to specify a different
      directory to unpack the distutils packages in misc.  (SF bug 784700).

    - Improved logging of the origin of subscription requests.

    - Bugs and patches: 832748 (unsubscribe_policy ignored for unsub button on
      member login page), 846681 (bounce disabled cookie was always out of
      date), 835870 (check VIRTUAL_HOST_OVERVIEW on through the web list
      creation), 835036 (global address change when the new address is already
      a member of one of the lists), 833384 (incorrect admin password on a
      hold message confirmation attachment would discard the message), 835012
      (fix permission on empty archive index), 816410 (confirmation page
      consistency), 834486 (catch empty charsets in the scrubber), 777444 (set
      the process's supplemental groups if possible), 860135 (ignore
      DiscardMessage exceptions during digest scrubbing), 828811 (reduce
      process size for list and admin overviews), 864674/864676 (problems
      accessing private archives and rosters with admin password), 865661
      (Tokio Kikuchi's i18n patches), 862906 (unicode prefix leak in admindb),
      841445 (setting new_member_options via config_list), n/a (fixed email
      command 'set delivery')

From ezk at cs.sunysb.edu  Wed Dec 31 13:37:40 2003
From: ezk at cs.sunysb.edu (Erez Zadok)
Date: Wed Dec 31 13:57:03 2003
Subject: [Mailman-Developers] Re: [Mailman-Announce] RELEASED Mailman 2.1.4 
In-Reply-To: Your message of "Wed, 31 Dec 2003 13:21:50 EST."
	<16371.5054.109107.157603@gargle.gargle.HOWL> 
Message-ID: <200312311837.hBVIbeIf020461@agora.fsl.cs.sunysb.edu>

In message <16371.5054.109107.157603@gargle.gargle.HOWL>, Barry A. Warsaw writes:

>     - Expanded header filter rules under Privacy -> Spam Filters.  Now you can
>       specify regular expression matches against any header, with specific
>       actions tied to those matches.

Yay!

Just what I asked for a couple of months ago (and was instructed to "hack it
myself" :-) I'm going to install this version on my server right away.

Thanks Barry, and a happy new year.

Erez.

From morley at yp-connect.net  Tue Dec 30 14:24:59 2003
From: morley at yp-connect.net (D&J Morley)
Date: Wed Dec 31 13:57:48 2003
Subject: [Mailman-Developers] Help me
Message-ID: <009f01c3cf0b$2a0275a0$9cd46dcb@1610777251>

http://www.british-genealogy.com/mailman/listinfo/s-arnold
As a list owner of the above list can you tell me why my own list is
rejecting my mail.
It seems your mailman thing says I do not exist?
no one will answer my emails from this UK web site.
Do I have to delete all my members as well am myself?
I do not know what ty do.
Jill Morley
list owner
s-arnold  list



From mjinks at uchicago.edu  Wed Dec 31 14:15:02 2003
From: mjinks at uchicago.edu (mjinks@uchicago.edu)
Date: Wed Dec 31 14:15:07 2003
Subject: [Mailman-Developers] Help me
In-Reply-To: <009f01c3cf0b$2a0275a0$9cd46dcb@1610777251>
References: <009f01c3cf0b$2a0275a0$9cd46dcb@1610777251>
Message-ID: <20031231191502.GG2141@uchicago.edu>

On Wed, Dec 31, 2003 at 05:54:59AM +1030, D&J Morley wrote:
> http://www.british-genealogy.com/mailman/listinfo/s-arnold
> As a list owner of the above list can you tell me why my own list is
> rejecting my mail.

Greetings.

I'm far from being a Mailman guru, but my guess is no, nobody will be
able to tell you without being able to look at your list's settings,
which none of us can do for you, since we don't have anything to do with
the system where your list is hosted.  This is a mailing list for
people who use the Mailman software package; we don't have any
association do with british-genealogy.com.

> It seems your mailman thing says I do not exist?

Or, british-genealogy.com's mailman thing says you do not exist. ;)

One possibility is that you are not subscribed to the list, and the list
is configured to reject mail from non-subscribers.  (Yes, I know you
said you're the owner of the list, but ownership and subscriber status
don't have anything to do with each other.)  But none of us can tell you
that for sure, it's just something I've seen from time to time on the
Mailman installation that I help run.

> no one will answer my emails from this UK web site.

If the people who operate the system where you house your mailing list
are not cooperative, you might want to consider moving your list to some
other site.  Just a thought, sorry that doesn't help you very much with
your current problem.

Good luck...
-- 
Michael Jinks, ENSA, NSIT, University of Chicago
"I have seen the future, and it makes no sense."