From richarde@eskom.co.za  Mon Nov  1 13:56:48 1999
From: richarde@eskom.co.za (Richard Ellerbrock)
Date: Mon, 01 Nov 1999 15:56:48 +0200
Subject: [Mailman-Developers] Patch against sync_members
Message-ID: <s81db84c.043@eskom.co.za>

Here is a little patch against the sync_members program to allow it to understand the following syntax:

sync_members -w=no -a=no -f - listname

The sync members command did not understand the - filename (read from stdio), even though the help for sync_members says that it does read from stdio.

--- sync_members        Mon Nov  1 15:51:51 1999
+++ sync_members.eskom  Mon Nov  1 15:30:48 1999
@@ -166,6 +166,11 @@
         filemembers = fp.readlines()
         fp.close()
 
+#        filemembers = sys.argv[i:]
+        # if there were no arguments on the command line, then it's probably
+        # a user error.  XXX this is questionable
+#        if not filemembers:
+#            usage(1, 'No addresses found on the command line')
     else:
         try:
             fp = open(filename)


--
Richard Ellerbrock
richarde@eskom.co.za



From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Sat Nov  6 05:15:06 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Sat, 6 Nov 1999 00:15:06 -0500 (EST)
Subject: [Mailman-Developers] Announcing Mailman 1.1
Message-ID: <14371.47450.186806.711568@anthem.cnri.reston.va.us>

I have just uploaded Mailman version 1.1 to www.list.org, and this
will hopefully soon be mirrored to ftp.gnu.org.  This release is
precipitated by the removal of all GIFs from the distribution.  There
have also been some performance improvements, although lots more can
still be done. ;)

See the NEWS file excerpt below for details of changes.  Sadly, the
internationalization effort has not yet been integrated (mostly due to
time constraints of the core maintainers).

Mailman, the GNU mailing list manager, is software to help manage
email discussion lists, much like Majordomo and Smartmail.  Unlike
most similar products, Mailman gives each mailing list a web page, and
allows users to subscribe, unsubscribe, etc. over the web.  Even the
list manager can administer his or her list entirely from the web.
Mailman also integrates most things people want to do with mailing
lists, including archiving, mail-to-news gateways, and so on.  Mailman
is writtein primarily in Python, with a little bit of C for security.

See http://www.list.org or
http://www.gnu.org/software/mailman/mailman.html for details and
downloading.

-Barry

-------------------- snip snip --------------------
- All GIFs removed.  See http://www.gnu.org/philosophy/gif.html for
  the reason why.

- Improvements to the Pipermail archiver which make things faster.
  Primary change is that the .txt files are not gzip'd on every posted
  message.  Instead, use the new cron script `nightly_gzip' to gzip
  the .txt file in batches (this means that the .txt file will lag
  behind the on-line archives a little).

- From the C drivers programs, Python is invoked with the -S option.
  This tells Python to avoid importing the site module, which can
  improve start up time of the Python process considerably.  Note that
  the command line script invocation has not been changed.

- New configuration variables PUBLIC_EXTERNAL_ARCHIVER and
  PRIVATE_EXTERNAL_ARCHIVER which can contain a shell command string
  for os.popen().  This can be used to invoke an external archiver
  instead of the bundled Pipermail archiver.  See Defaults.py for
  details.

- new script `bin/find_member' which can be used to search for a
  member by regular expression.

- More child processes are reaped, which should eliminate most
  occurances of zombie processes.

- A few small miscellaneous bug fixes (including PR#99, PR#107) and
  improvements to the file locking algorithms.
-------------------- snip snip --------------------

<p><a href="http://www.list.org/">Mailman 1.1</a> - the GNU mailing
list manager, implemented primarily in Python.  (05-Nov-1999)


From gorgo@caesar.elte.hu  Sat Nov  6 13:16:13 1999
From: gorgo@caesar.elte.hu (Gergely Madarasz)
Date: Sat, 6 Nov 1999 14:16:13 +0100 (MET)
Subject: [Mailman-Developers] Announcing Mailman 1.1
In-Reply-To: <14371.47450.186806.711568@anthem.cnri.reston.va.us>
Message-ID: <Pine.A32.3.96.991106141519.33077c-100000@caesar.power.elte.hu>

On Sat, 6 Nov 1999, Barry A. Warsaw wrote:

> 
> I have just uploaded Mailman version 1.1 to www.list.org, and this
> will hopefully soon be mirrored to ftp.gnu.org.  This release is
> precipitated by the removal of all GIFs from the distribution.  There
> have also been some performance improvements, although lots more can
> still be done. ;)

Ugh... just in time to be included in debian potato before freeze :)

-- 
Madarasz Gergely           gorgo@caesar.elte.hu         gorgo@linux.rulez.org
      It's practically impossible to look at a penguin and feel angry.
          Egy pingvinre gyakorlatilag lehetetlen haragosan nezni.
                    HuLUG: http://mlf.linux.rulez.org/



From grin@tolna.net  Mon Nov  8 02:10:55 1999
From: grin@tolna.net (Peter Gervai)
Date: Mon, 8 Nov 1999 03:10:55 +0100
Subject: [Mailman-Developers] running on nice
Message-ID: <19991108031055.T29543@mail.tolna.net>

Hello,

I got angry at mailman/python eating up my resources all the time,
so I have put some 

os.nice(10) 

into deliver,post and mailcmd scripts. Maybe others would find this
appealing and would worth a configurable variable somewhere.

bye,
grin


From richarde@eskom.co.za  Mon Nov  8 13:44:59 1999
From: richarde@eskom.co.za (Richard Ellerbrock)
Date: Mon, 08 Nov 1999 15:44:59 +0200
Subject: [Mailman-Developers] ABEND: problem with sync_members command
Message-ID: <s826f003.067@eskom.co.za>

When I want to sync a huge list of e-mail addresses into a mailing list, I get the following ABEND:

[root@lisa bin]# /home/mailman/bin/sync_members -w=no -a=no -f /tmp/tt test
Traceback (innermost last):
  File "/home/mailman/bin/sync_members", line 257, in ?
    main()
  File "/home/mailman/bin/sync_members", line 239, in main
    mlist.ApprovedAddMember(addr, pw, digest, welcome, notifyadmin)
  File "/home/mailman/Mailman/MailList.py", line 944, in ApprovedAddMember
    raise e, v
Mailman.Errors.MMBadEmailError
[root@lisa bin]# 

This is with Mailman 1.1 freshly downloaded. sync_members does not complain about any invalid addresses. The number of addresses that I want to sync are over 3000! Could this be a problem?

--
Richard Ellerbrock
richarde@eskom.co.za



From jafo@tummy.com  Mon Nov  8 18:45:18 1999
From: jafo@tummy.com (Sean Reifschneider)
Date: Mon, 8 Nov 1999 11:45:18 -0700
Subject: [Mailman-Developers] ABEND: problem with sync_members command
In-Reply-To: <s826f003.067@eskom.co.za>; from Richard Ellerbrock on Mon, Nov 08, 1999 at 03:44:59PM +0200
References: <s826f003.067@eskom.co.za>
Message-ID: <19991108114518.F2540@tummy.com>

On Mon, Nov 08, 1999 at 03:44:59PM +0200, Richard Ellerbrock wrote:
>This is with Mailman 1.1 freshly downloaded. sync_members does not
>complain about any invalid addresses. The number of addresses that I
>want to sync are over 3000! Could this be a problem?

I don't know, but last week I created a new list and freshly inserted over
3000 addresses into it with no problems.

Sean
-- 
 "Engineering Tablets?  Does that mean if I swallow one, I'll be an engineer?"
                 -- Evelyn Mitchell
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
URL: <http://www.tummy.com/xvscan> HP-UX/Linux/FreeBSD/BSDOS scanning software.


From Luyin Zhao" <lzhao@cse.unl.edu  Tue Nov  9 02:53:05 1999
From: Luyin Zhao" <lzhao@cse.unl.edu (Luyin Zhao)
Date: Mon, 8 Nov 1999 20:53:05 -0600
Subject: [Mailman-Developers] Questionnaire For My Project
Message-ID: <027401bf2a5d$8e3dc080$c781d6ab@luyinzha>

This is a multi-part message in MIME format.

------=_NextPart_000_0271_01BF2A2B.411F64C0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable

Dear Mailman,
     I'm a graduate student (computer science) in University=20
of Nebraska-Lincoln. The Questionnaire for open source testing=20
below is for a paper I'm working on. Hope you can spend=20
five minutes to finish it in your busy time. Any of your=20
effort will be greatly appreciated!
Luyin
=20
Questionnaire for Open Source Testing
****************************************************
1. What programming language is used in developing your product
"Mailman 1.1":?
****************************************************
2. How many developers were involved in your project?
****************************************************
3. When do you begin to do testing?=20
    a. Requirement Analysis Phase=20
    b. Functional design Phase=20
    c. Internal Design Phase=20
    d. Implementation Phase=20
    e. After Implementation=20
    Note: Functional design is to describe the features of a system from
      technique-oriented perspective compared with the user-oriented=20
      perspective of requirement analysis. Internal design is to model=20
      the implementation of system, such as class diagrams.
Answer:
****************************************************
4. The time you spent in testing compared with the total time of =
development?
    a. <20%  b. 20%-40%  c. 40%-60%  d. 60-80%  e. >80%
Answer:
****************************************************
5. How do you prepare for your testing (using plan or schedule)?=20
    a. Written plan which was modified several times =20
    b. One plan draft without further modification =20
    c. I prepare it in my brain =20
    d. I have no plan
Answer:
****************************************************
6. Do you inspect the following items?
    a. Requirement Documentation (if you have) =20
    b. Design Documentation (if you have) =20
    c. Source code (besides relying on compiler and program execution to =

find faults in code)
Answer:
****************************************************
7. There are some defects resulted from the unclear definition of =
requirements.
   In the total defects of this category you found, approximately what=20
   percentage were found in code inspections, in unit tests and in =
system=20
   tests, respectively?
   a. <20%  b. 20%-40%  c. 40%-60%  d. 60-80%  e. >80%   f. Not =
applicable
Answer:     ,       ,    =20
****************************************************
8. The percent of time you spent in document inspection (compared with =
total=20
   development time) is:
    a. <20%  b. 20%-40%  c. 40%-60%  d. 60-80%  e. >80%   f. Not =
applicable
Answer:
****************************************************
9. How many people did you ask to check your documents or source code?
   Do you think it is useful?
    a. No =20
    b. A little bit =20
    c. Useful but not necessary =20
    d. They found lots of defects that I haven=92t found =20
    e. Absolutely necessary
Answer:
****************************************************
10. Do you use testing tools during your development? The name of it?
Answer:
****************************************************
11. What is the basis of your testing?
    a. Test whether system implemented what user need =20
    b. Test whether system implemented technical features =20
    c. Find faults =20
    d. All the above.
Answer:
****************************************************
12. What strategy did you adopt in choosing your test cases? Please list =
them
    according to the importance of finding defects of your system =
(descending)?
    a. Choose sample of valid inputs =20
    b. Choose those inputs most likely to cause failure =20
    c. Choose inputs according to your experience =20
    d. Other (specify            )
Answer:
****************************************************
13. If you do coverage control, what percent of the code (lines of code) =
do=20
    you think are covered in your test?
    a. <20%  b. 20%-40%  c. 40%-60%  d. 60-80%  e. >80%   f. Not =
Applicable
Answer:
****************************************************
14. In defects you found, what percent of the following problem =
categories=20
should be found in requirements phase? in design phase? in unit test ?
in integration test?
    a. <20%  b. 20%-40%  c. 40%-60%  d. 60-80%  e. >80%   F. Not =
Applicable
Answer:
****************************************************
15. In which areas did you find most of the defects when  you integrate =
and=20
    sell products (someone sell open source products such as RedHat)?
    a. User interface-related problems =20
    b. Database-related problems =20
    c. Network-related problems =20
    d. Logical =20
    e. Other(specify   )
    f. Not Applicable
Answer:
=20
Luyin Zhao
535 N23 Street, #10
Lincoln, NE 68503
(402)438-9511

------=_NextPart_000_0271_01BF2A2B.411F64C0
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Dgb2312 http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Dear =
Mailman,<BR>&nbsp;&nbsp;&nbsp;&nbsp; I'm a=20
graduate student (computer science) in University <BR>of =
Nebraska-Lincoln. The=20
Questionnaire for open source testing <BR>below is for a paper I'm =
working on.=20
Hope you can spend <BR>five minutes to finish it in your busy time. Any =
of your=20
<BR>effort will be greatly =
appreciated!<BR>Luyin<BR>&nbsp;<BR>Questionnaire for=20
Open Source=20
Testing<BR>****************************************************<BR>1. =
What=20
programming language is used in developing your product<BR>&quot;Mailman =

1.1&quot;:?<BR>****************************************************<BR>2.=
 How=20
many developers were involved in your=20
project?<BR>****************************************************<BR>3. =
When do=20
you begin to do testing? <BR>&nbsp;&nbsp;&nbsp; a. Requirement Analysis =
Phase=20
<BR>&nbsp;&nbsp;&nbsp; b. Functional design Phase <BR>&nbsp;&nbsp;&nbsp; =
c.=20
Internal Design Phase <BR>&nbsp;&nbsp;&nbsp; d. Implementation Phase=20
<BR>&nbsp;&nbsp;&nbsp; e. After Implementation <BR>&nbsp;&nbsp;&nbsp; =
Note:=20
Functional design is to describe the features of a system=20
from<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; technique-oriented perspective =
compared=20
with the user-oriented <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; perspective of =

requirement analysis. Internal design is to model=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the implementation of system, such as =
class=20
diagrams.<BR>Answer:<BR>*************************************************=
***<BR>4.=20
The time you spent in testing compared with the total time of=20
development?<BR>&nbsp;&nbsp;&nbsp; a. &lt;20%&nbsp; b. 20%-40%&nbsp; c.=20
40%-60%&nbsp; d. 60-80%&nbsp; e.=20
&gt;80%<BR>Answer:<BR>***************************************************=
*<BR>5.=20
How do you prepare for your testing (using plan or schedule)?=20
<BR>&nbsp;&nbsp;&nbsp; a. Written plan which was modified several =
times&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp; b. One plan draft without further =
modification&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp; c. I prepare it in my brain&nbsp; =
<BR>&nbsp;&nbsp;&nbsp;=20
d. I have no=20
plan<BR>Answer:<BR>****************************************************<B=
R>6. Do=20
you inspect the following items?<BR>&nbsp;&nbsp;&nbsp; a. Requirement=20
Documentation (if you have)&nbsp; <BR>&nbsp;&nbsp;&nbsp; b. Design =
Documentation=20
(if you have)&nbsp; <BR>&nbsp;&nbsp;&nbsp; c. Source code (besides =
relying on=20
compiler and program execution to <BR>find faults in=20
code)<BR>Answer:<BR>****************************************************<=
BR>7.=20
There are some defects resulted from the unclear definition of=20
requirements.<BR>&nbsp;&nbsp; In the total defects of this category you =
found,=20
approximately what <BR>&nbsp;&nbsp; percentage were found in code =
inspections,=20
in unit tests and in system <BR>&nbsp;&nbsp; tests,=20
respectively?<BR>&nbsp;&nbsp; a. &lt;20%&nbsp; b. 20%-40%&nbsp; c. =
40%-60%&nbsp;=20
d. 60-80%&nbsp; e. &gt;80%&nbsp;&nbsp; f. Not=20
applicable<BR>Answer:&nbsp;&nbsp;&nbsp;&nbsp;=20
,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ,&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>****************************************************<BR>8. The =
percent of=20
time you spent in document inspection (compared with total =
<BR>&nbsp;&nbsp;=20
development time) is:<BR>&nbsp;&nbsp;&nbsp; a. &lt;20%&nbsp; b. =
20%-40%&nbsp; c.=20
40%-60%&nbsp; d. 60-80%&nbsp; e. &gt;80%&nbsp;&nbsp; f. Not=20
applicable<BR>Answer:<BR>************************************************=
****<BR>9.=20
How many people did you ask to check your documents or source=20
code?<BR>&nbsp;&nbsp; Do you think it is useful?<BR>&nbsp;&nbsp;&nbsp; =
a.=20
No&nbsp; <BR>&nbsp;&nbsp;&nbsp; b. A little bit&nbsp; =
<BR>&nbsp;&nbsp;&nbsp; c.=20
Useful but not necessary&nbsp; <BR>&nbsp;&nbsp;&nbsp; d. They found lots =
of=20
defects that I haven=92t found&nbsp; <BR>&nbsp;&nbsp;&nbsp; e. =
Absolutely=20
necessary<BR>Answer:<BR>*************************************************=
***<BR>10.=20
Do you use testing tools during your development? The name of=20
it?<BR>Answer:<BR>****************************************************<BR=
>11.=20
What is the basis of your testing?<BR>&nbsp;&nbsp;&nbsp; a. Test whether =
system=20
implemented what user need&nbsp; <BR>&nbsp;&nbsp;&nbsp; b. Test whether =
system=20
implemented technical features&nbsp; <BR>&nbsp;&nbsp;&nbsp; c. Find =
faults&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp; d. All the=20
above.<BR>Answer:<BR>****************************************************=
<BR>12.=20
What strategy did you adopt in choosing your test cases? Please list=20
them<BR>&nbsp;&nbsp;&nbsp; according to the importance of finding =
defects of=20
your system (descending)?<BR>&nbsp;&nbsp;&nbsp; a. Choose sample of =
valid=20
inputs&nbsp; <BR>&nbsp;&nbsp;&nbsp; b. Choose those inputs most likely =
to cause=20
failure&nbsp; <BR>&nbsp;&nbsp;&nbsp; c. Choose inputs according to your=20
experience&nbsp; <BR>&nbsp;&nbsp;&nbsp; d. Other=20
(specify&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
)<BR>Answer:<BR>****************************************************<BR>1=
3. If=20
you do coverage control, what percent of the code (lines of code) do=20
<BR>&nbsp;&nbsp;&nbsp; you think are covered in your =
test?<BR>&nbsp;&nbsp;&nbsp;=20
a. &lt;20%&nbsp; b. 20%-40%&nbsp; c. 40%-60%&nbsp; d. 60-80%&nbsp; e.=20
&gt;80%&nbsp;&nbsp; f. Not=20
Applicable<BR>Answer:<BR>************************************************=
****<BR>14.=20
In defects you found, what percent of the following problem categories=20
<BR>should be found in requirements phase? in design phase? in unit test =
?<BR>in=20
integration test?<BR>&nbsp;&nbsp;&nbsp; a. &lt;20%&nbsp; b. =
20%-40%&nbsp; c.=20
40%-60%&nbsp; d. 60-80%&nbsp; e. &gt;80%&nbsp;&nbsp; F. Not=20
Applicable<BR>Answer:<BR>************************************************=
****<BR>15.=20
In which areas did you find most of the defects when&nbsp; you integrate =
and=20
<BR>&nbsp;&nbsp;&nbsp; sell products (someone sell open source products =
such as=20
RedHat)?<BR>&nbsp;&nbsp;&nbsp; a. User interface-related problems&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp; b. Database-related problems&nbsp; =
<BR>&nbsp;&nbsp;&nbsp;=20
c. Network-related problems&nbsp; <BR>&nbsp;&nbsp;&nbsp; d. =
Logical&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp; e. Other(specify&nbsp;&nbsp; =
)<BR>&nbsp;&nbsp;&nbsp; f.=20
Not Applicable<BR>Answer:<BR>&nbsp;</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Luyin Zhao<BR>535 N23 Street, =
#10<BR>Lincoln, NE=20
68503<BR>(402)438-9511</FONT></DIV></BODY></HTML>

------=_NextPart_000_0271_01BF2A2B.411F64C0--



From richarde@eskom.co.za  Tue Nov  9 07:09:45 1999
From: richarde@eskom.co.za (Richard Ellerbrock)
Date: Tue, 09 Nov 1999 09:09:45 +0200
Subject: [Mailman-Developers] ABEND: problem with sync_members
 command
Message-ID: <s827e4df.049@eskom.co.za>

Ok, I have found the problem. The check routines that validate an e-mail address does not pick up addresses with spaces in them. Thus, the following will cause an ABEND:

richarde. test@eskom.co.za 

Easy to reproduce. It must be in the code that checks e-mail addresses against a regular expression.

Well, I doubt that it will be fixed as I submitted a patch against sync_members to allow getting input from stdio as stated in the help for the command. Nothing as yet.

Is anything happening with mailman development?

--
Richard Ellerbrock
richarde@eskom.co.za

>>> Sean Reifschneider <jafo@tummy.com> 1999/11/08 08:45:18 >>>
On Mon, Nov 08, 1999 at 03:44:59PM +0200, Richard Ellerbrock wrote:
>This is with Mailman 1.1 freshly downloaded. sync_members does not
>complain about any invalid addresses. The number of addresses that I
>want to sync are over 3000! Could this be a problem?

I don't know, but last week I created a new list and freshly inserted over
3000 addresses into it with no problems.

Sean
-- 
 "Engineering Tablets?  Does that mean if I swallow one, I'll be an engineer?"
                 -- Evelyn Mitchell
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
URL: <http://www.tummy.com/xvscan> HP-UX/Linux/FreeBSD/BSDOS scanning software.

_______________________________________________
Mailman-Developers maillist  -  Mailman-Developers@python.org 
http://www.python.org/mailman/listinfo/mailman-developers



From lindsey@ncsa.uiuc.edu  Tue Nov  9 07:40:37 1999
From: lindsey@ncsa.uiuc.edu (Christopher Lindsey)
Date: Tue, 9 Nov 1999 01:40:37 -0600 (CST)
Subject: [Mailman-Developers] ABEND: problem with sync_members
In-Reply-To: <s827e4df.049@eskom.co.za> from "Richard Ellerbrock" at Nov 9, 99 09:09:45 am
Message-ID: <199911090740.BAA32540@ferret.ncsa.uiuc.edu>

> Ok, I have found the problem. The check routines that validate an e-mail address does not pick up addresses with spaces in them. Thus, the following will cause an ABEND:
> 
> richarde. test@eskom.co.za 

For what it's worth, that's not an RFC-compliant address.  Any addresses
with spaces need to be enclosed within quotations, i.e

   "richarde. test"@eskom.co.za 

If I remember, most of the address-related routines in Mailman split
on whitespace when extracting addresses from headers, in the Web interface,
etc., so the issue is unfortunately a lot more complex. 

As far as I know there's currently no way to gracefully handle addresses
with spaces in them.

Another issue I'd like to eventually deal with is plus-addressing, so 
Mailman interprets lindsey@example.com = lindsey+listname@example.com
for purposes of "authentication."

Chris


From richarde@eskom.co.za  Tue Nov  9 08:27:23 1999
From: richarde@eskom.co.za (Richard Ellerbrock)
Date: Tue, 09 Nov 1999 10:27:23 +0200
Subject: [Mailman-Developers] ABEND: problem with sync_members
Message-ID: <s827f713.089@eskom.co.za>

>> Ok, I have found the problem. The check routines that validate an e-mail 
>address does not pick up addresses with spaces in them. Thus, the following 
>will cause an ABEND:
>> 
>> richarde. test@eskom.co.za 
>
>For what it's worth, that's not an RFC-compliant address.  Any addresses
>with spaces need to be enclosed within quotations, i.e
>
>   "richarde. test"@eskom.co.za 

Correct. I have written a routine that grabs addresses from a database. It is rather strange what people enter as e-mail addresses. I then sync this to a mailing list.

What I have done to get around the problem is to modify my SQL statement to exclude addresses with spaces in them. Also works :-)

I had to modify sync_members to accept input from stdio though.


--
Richard Ellerbrock
richarde@eskom.co.za



From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Wed Nov 10 17:31:40 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Wed, 10 Nov 1999 12:31:40 -0500 (EST)
Subject: [Mailman-Developers] Massive changes (Long)
Message-ID: <14377.44028.822009.15906@anthem.cnri.reston.va.us>

Folks, I have some rather massive changes to check into the CVS tree,
which I'm going to explain below.  Grab a cup of coffee and sit back.
:)

I should note that while I've done a lot of testing of this stuff, I'm
sure I've missed things.  I do not recommend using any of this on a
production system, but I would definitely appreciate another set of
eyes and hands taking a look.  I think I have a way to selectively
migrate lists to a new Mailman installation one at a time, so I will
try some of my test lists on python.org.  If all goes well, I may make
y'all guinea pigs in the next round of experiments :)

These changes were precipitated by the observation of occasional poor
performance, and the intermittent reports of duplicate messages.  I
actually gathered enough data on python.org that implicate Mailman's
built-in bulk mailer.  So I wanted to experiment with alternative
delivery strategies.  In the process I got a new Ultra2 for python.org
and decided it was time to play with a different MTA, so I sucked down
Postfix and installed it instead of sendmail.

What I wanted was an architecture that would let us drop in different
delivery schemes easily, so that we could experiment with the best,
and also so sites could easily add whatever delivery machinery made
the most sense for them.  I strongly suspect that no one scheme that
Mailman coudl bundle will be right for everyone.

For a while now, I've hated the tangle of code that gets called when a
message is being delivered.  So I've essentially ripped all that out
for an architecture that I've talked about to a few people already.
The idea is that when a message comes into the system, it is handled
by a "pipeline".  In Python terms, the pipeline is simply a list of
modules, all of which have a function called `process' that takes two
arguments: a MailList instance and a Message instance.  MailLists you
know.  Messages are a subclass of rfc822.Messages with a little bit of
extra stuff for convenience.  Since rfc822.Message now supports a
writeable interface, I was able to get rid of Message.IncomingMessage,
Message.OutgoingMessage, and Message.NewsMessage.

Here's the entire contents of MailList.Post():

    # msg should be an Message.Message object.
    def Post(self, msg):
	self.IsListInitialized()
        # TBD: this is bogus and will later be configurable
        import Mailman.Handlers.HandlerAPI
        Mailman.Handlers.HandlerAPI.process(self, msg)
	self.Save()

You'll see that that is a little bit shorter than what it used to be
:).  `Handlers' is a new package inside Mailman which contains all the
modules for the pipeline.  HandlerAPI.process() basically runs down
the list of pipeline modules, calling each in turn.  The specs for the
<handler>.process() functions say that their return value is ignored,
and they raise an exception if processing of the message is supposed
to stop propagating.

Here's the current list of pipeline modules for normal message
delivery:

    pipeline = ['SpamDetect',
                'Approve',
                'Hold',
                'Cleanse',
                'CookHeaders',
                'ToDigest',
                'ToArchive',
                'ToUsenet',
                'CalcRecips',
                'Decorate',
                'Sendmail',
                'Acknowledge',
                'AfterDelivery',
                ]

The idea here is that each pipeline module does one small thing and
one thing only.  For example, Approve.process() tries to figure out if
the message has been pre-approved.  It will also look for an Approved:
header with a valid password.  All communication between handlers
happens via attributes on the message object, so in the case of the
Approve handler, if it finds a valid "Approve: password" header, it
sets "msg.approved = 1".  Other modules (notably SpamDetect and Hold)
will look for this attribute and short circuit if it finds a true
value.

In a similar vein, ToArchive and ToDigest will look for the `isdigest'
attribute.  If found and true, then the message is a digest so it
won't be sent to the archive, nor will it be appended to the currently
building digest.

Now the neat thing is the Sendmail module.  It's not clever at all, in
fact it just popen's a sendmail (or sendmail-compatible, e.g. postfix)
process, gives the recip addrs on the command line, and pipes the
message to the proc's stdin.  The one complication is that it splits
up the recipients if necessary to keep the command line length
manageable.  What I think is neat is that you could implement an
SMTPDeliver module which uses smtplib.py, or even convert to using
Mailman's current bulk mailer (which I haven't done), or a delivery
scheme of your own choosing.  It should be quite easy to drop in just
drop in this component while keeping everything else the same.  The
Sendmail module rqeuires that the msg object has an attribute called
`recips' which is a list of addresses to send the message to.  The
CalcRecips module sets this attribute.

A couple of things to notice.  First, proper delivery of the message
requires the correct order in the pipeline.  Put Acknowledge before
Sendmail and those who want acks of their messages would get them
before the message was actually sent.  Also, while this seems to work
well for my simple tests, I think I need to play with more aspects
under more realistic load to figure out whether this approach will
work in the long run.  Finally, there's the question of incoming
messages (say injected from Usenet, or via the -request address).  I
think a pipeline will work well here too, e.g. I envision a pipeline
of bounce detectors, but I'm not sure yet how this will integrate with
the outgoing pipeline.

A couple of other random but important notes.  I've also significantly
revamped the whole admin request stuff.  Held messages and
subscriptions are no longer kept in the list object.  This should make
your config.db files considerably smaller and faster to load, and will
hopefully improve overall performance.  All that information is now
kept in a separate database file, which is currently implemented using
Python's anydbm module (this might change).  The good thing is that
this file is only touched when a message or subscription is held, or
when you hit the admindb web page.

I've decided to finally make Python 1.5.2 the minimum supported
platform.  It's been out since April, is very stable, is available for
all platforms (and I think there are RPMs available), and is much much
MUCH better than any previous version of Python.  I'm tired of trying
to keep track of backwards compatibility issues.  So the next version
of Mailman will require at least Python 1.5.2.  I should note that
there will /not/ be a Python 1.5.3 -- Guido's decided that the next
release will be 1.6, but that will definitely not be out (other than
via the anonCVS tree) until next year some time.

So... I'm going to check all these changes in so that I can continue
testing.  I'll hopefully also be ripping out lots more unused code.
I'm not sure how much more time I'm going to be hacking on it, but I
need to get this stuff working for python.org so at least until then.

Apologies in advance to the I18N'ers for not getting to that stuff,
and for making so many changes under the hood.  If this stuff turns
out to work well, I'll try to spend some time getting those mods
integrated.

Thanks,
-Barry


From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Wed Nov 10 20:29:44 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Wed, 10 Nov 1999 15:29:44 -0500 (EST)
Subject: [Mailman-Developers] Massive changes (Long)
References: <14377.44028.822009.15906@anthem.cnri.reston.va.us>
Message-ID: <14377.54712.308533.182882@anthem.cnri.reston.va.us>

Just to let y'all know, I've finished this round of check-ins.  I will
be testing stuff out with the current snapshot and making any fixes
that are necessary.  If you find problems, please let me know.

-Barry


From bwarsaw@python.org  Fri Nov 12 20:00:30 1999
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Fri, 12 Nov 1999 15:00:30 -0500 (EST)
Subject: [Mailman-Developers] Changes working, and list moved
Message-ID: <14380.29150.737226.76974@anthem.cnri.reston.va.us>

Hey folks, the purpose of this message is twofold.  First, it's to let
you know that I feel pretty confident about the new changes, at least
insofar as they system seems to be working pretty well.  I don't yet
know what impact, if any there will be on performance.

Second, I've moved this mailing list to our new server so at least it
should /seem/ faster (the new one is an Ultra2, the old one is a
Sparc5).  I'll be keeping an eye on this list over the next couple of
days to make sure the new version is working properly.  If so, then
I'll probably start moving all the existing python.org mailing lists
over to it (once I've verified our sysadmins are actually backing up
the Ultra2).

So you guys are the guinea pigs for the new changes.  You should not
notice any differences; the email addresses are unchanged, as are the
URLs.  You'll notice the new hostname leak in a couple of places
(e.g. as URLs for the Mailman logo and the public archives), but those
aren't important enough to fix at the moment.

If you notice /anything/ strange going on, first try to email this
list.  If you suspect that the messages aren't getting through, email
me directly at bwarsaw@python.org.

Okay, have fun!
-Barry


From bwarsaw@python.org  Fri Nov 12 20:08:39 1999
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Fri, 12 Nov 1999 15:08:39 -0500 (EST)
Subject: [Mailman-Developers] Changes working, and list moved
Message-ID: <14380.29639.55451.890041@anthem.cnri.reston.va.us>

Hey folks, the purpose of this message is twofold.  First, it's to let
you know that I feel pretty confident about the new changes, at least
insofar as they system seems to be working pretty well.  I don't yet
know what impact, if any there will be on performance.

Second, I've moved this mailing list to our new server so at least it
should /seem/ faster (the new one is an Ultra2, the old one is a
Sparc5).  I'll be keeping an eye on this list over the next couple of
days to make sure the new version is working properly.  If so, then
I'll probably start moving all the existing python.org mailing lists
over to it (once I've verified our sysadmins are actually backing up
the Ultra2).

So you guys are the guinea pigs for the new changes.  You should not
notice any differences; the email addresses are unchanged, as are the
URLs.  You'll notice the new hostname leak in a couple of places
(e.g. as URLs for the Mailman logo and the public archives), but those
aren't important enough to fix at the moment.

If you notice /anything/ strange going on, first try to email this
list.  If you suspect that the messages aren't getting through, email
me directly at bwarsaw@python.org.

Okay, have fun!
-Barry


From bwarsaw@python.org  Fri Nov 12 20:09:36 1999
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Fri, 12 Nov 1999 15:09:36 -0500 (EST)
Subject: [Mailman-Developers] Changes working, and list moved
Message-ID: <14380.29696.616826.310655@anthem.cnri.reston.va.us>

Hey folks, the purpose of this message is twofold.  First, it's to let
you know that I feel pretty confident about the new changes, at least
insofar as they system seems to be working pretty well.  I don't yet
know what impact, if any there will be on performance.

Second, I've moved this mailing list to our new server so at least it
should /seem/ faster (the new one is an Ultra2, the old one is a
Sparc5).  I'll be keeping an eye on this list over the next couple of
days to make sure the new version is working properly.  If so, then
I'll probably start moving all the existing python.org mailing lists
over to it (once I've verified our sysadmins are actually backing up
the Ultra2).

So you guys are the guinea pigs for the new changes.  You should not
notice any differences; the email addresses are unchanged, as are the
URLs.  You'll notice the new hostname leak in a couple of places
(e.g. as URLs for the Mailman logo and the public archives), but those
aren't important enough to fix at the moment.

If you notice /anything/ strange going on, first try to email this
list.  If you suspect that the messages aren't getting through, email
me directly at bwarsaw@python.org.

Okay, have fun!
-Barry


From bwarsaw@python.org  Fri Nov 12 20:13:41 1999
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Fri, 12 Nov 1999 15:13:41 -0500 (EST)
Subject: [Mailman-Developers] Changes working, and list moved
Message-ID: <14380.29941.960244.326705@anthem.cnri.reston.va.us>

Hey folks, the purpose of this message is twofold.  First, it's to let
you know that I feel pretty confident about the new changes, at least
insofar as they system seems to be working pretty well.  I don't yet
know what impact, if any there will be on performance.

Second, I've moved this mailing list to our new server so at least it
should /seem/ faster (the new one is an Ultra2, the old one is a
Sparc5).  I'll be keeping an eye on this list over the next couple of
days to make sure the new version is working properly.  If so, then
I'll probably start moving all the existing python.org mailing lists
over to it (once I've verified our sysadmins are actually backing up
the Ultra2).

So you guys are the guinea pigs for the new changes.  You should not
notice any differences; the email addresses are unchanged, as are the
URLs.  You'll notice the new hostname leak in a couple of places
(e.g. as URLs for the Mailman logo and the public archives), but those
aren't important enough to fix at the moment.

If you notice /anything/ strange going on, first try to email this
list.  If you suspect that the messages aren't getting through, email
me directly at bwarsaw@python.org.

Okay, have fun!
-Barry


From bwarsaw@python.org  Fri Nov 12 20:16:07 1999
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Fri, 12 Nov 1999 15:16:07 -0500 (EST)
Subject: [Mailman-Developers] Changes working, and list moved
Message-ID: <14380.30087.203052.100118@anthem.cnri.reston.va.us>

Hey folks, the purpose of this message is twofold.  First, it's to let
you know that I feel pretty confident about the new changes, at least
insofar as they system seems to be working pretty well.  I don't yet
know what impact, if any there will be on performance.

Second, I've moved this mailing list to our new server so at least it
should /seem/ faster (the new one is an Ultra2, the old one is a
Sparc5).  I'll be keeping an eye on this list over the next couple of
days to make sure the new version is working properly.  If so, then
I'll probably start moving all the existing python.org mailing lists
over to it (once I've verified our sysadmins are actually backing up
the Ultra2).

So you guys are the guinea pigs for the new changes.  You should not
notice any differences; the email addresses are unchanged, as are the
URLs.  You'll notice the new hostname leak in a couple of places
(e.g. as URLs for the Mailman logo and the public archives), but those
aren't important enough to fix at the moment.

If you notice /anything/ strange going on, first try to email this
list.  If you suspect that the messages aren't getting through, email
me directly at bwarsaw@python.org.

Okay, have fun!
-Barry


From bwarsaw@python.org  Fri Nov 12 20:39:04 1999
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Fri, 12 Nov 1999 15:39:04 -0500 (EST)
Subject: [Mailman-Developers] Changes working, and list moved
Message-ID: <14380.31464.240034.731424@anthem.cnri.reston.va.us>

Hey folks, the purpose of this message is twofold.  First, it's to let
you know that I feel pretty confident about the new changes, at least
insofar as they system seems to be working pretty well.  I don't yet
know what impact, if any there will be on performance.

Second, I've moved this mailing list to our new server so at least it
should /seem/ faster (the new one is an Ultra2, the old one is a
Sparc5).  I'll be keeping an eye on this list over the next couple of
days to make sure the new version is working properly.  If so, then
I'll probably start moving all the existing python.org mailing lists
over to it (once I've verified our sysadmins are actually backing up
the Ultra2).

So you guys are the guinea pigs for the new changes.  You should not
notice any differences; the email addresses are unchanged, as are the
URLs.  You'll notice the new hostname leak in a couple of places
(e.g. as URLs for the Mailman logo and the public archives), but those
aren't important enough to fix at the moment.

If you notice /anything/ strange going on, first try to email this
list.  If you suspect that the messages aren't getting through, email
me directly at bwarsaw@python.org.

Okay, have fun!
-Barry


From bwarsaw@python.org  Fri Nov 12 20:42:26 1999
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Fri, 12 Nov 1999 15:42:26 -0500 (EST)
Subject: [Mailman-Developers] Changes working, and list moved
Message-ID: <14380.31666.51895.556833@anthem.cnri.reston.va.us>

Hey folks, the purpose of this message is twofold.  First, it's to let
you know that I feel pretty confident about the new changes, at least
insofar as they system seems to be working pretty well.  I don't yet
know what impact, if any there will be on performance.

Second, I've moved this mailing list to our new server so at least it
should /seem/ faster (the new one is an Ultra2, the old one is a
Sparc5).  I'll be keeping an eye on this list over the next couple of
days to make sure the new version is working properly.  If so, then
I'll probably start moving all the existing python.org mailing lists
over to it (once I've verified our sysadmins are actually backing up
the Ultra2).

So you guys are the guinea pigs for the new changes.  You should not
notice any differences; the email addresses are unchanged, as are the
URLs.  You'll notice the new hostname leak in a couple of places
(e.g. as URLs for the Mailman logo and the public archives), but those
aren't important enough to fix at the moment.

If you notice /anything/ strange going on, first try to email this
list.  If you suspect that the messages aren't getting through, email
me directly at bwarsaw@python.org.

Okay, have fun!
-Barry


From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Fri Nov 12 20:46:01 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Fri, 12 Nov 1999 15:46:01 -0500 (EST)
Subject: [Mailman-Developers] Changes working, and list moved
References: <14380.31666.51895.556833@anthem.cnri.reston.va.us>
Message-ID: <14380.31881.124703.786223@anthem.cnri.reston.va.us>

This is another test.  Please ignore.
-Barry


From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Fri Nov 12 20:48:17 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Fri, 12 Nov 1999 15:48:17 -0500 (EST)
Subject: [Mailman-Developers] Changes working, and list moved
References: <14380.31666.51895.556833@anthem.cnri.reston.va.us>
 <14380.31881.124703.786223@anthem.cnri.reston.va.us>
Message-ID: <14380.32017.428596.333228@anthem.cnri.reston.va.us>

Okay, I think I've now got Mailman 1.1+ and Postfix working nicely
together.  You might see a couple of extra messages in the archives
though :)

-Barry


From bwarsaw@server.python.net  Sat Nov 13 00:20:33 1999
From: bwarsaw@server.python.net (bwarsaw@server.python.net)
Date: 13 Nov 1999 00:20:33 -0000
Subject: [Mailman-Developers] test from off-site
Message-ID: <19991113002033.32632.qmail@server.python.net>

I'm sending this from the starship.  Please ignore.
-Barry


From bwarsaw@server.python.net  Sat Nov 13 00:33:16 1999
From: bwarsaw@server.python.net (bwarsaw@server.python.net)
Date: 13 Nov 1999 00:33:16 -0000
Subject: [Mailman-Developers] test #2
Message-ID: <19991113003316.39.qmail@server.python.net>

plz ignore


From pioppo@ferrara.linux.it  Sun Nov 14 13:53:39 1999
From: pioppo@ferrara.linux.it (Pioppo)
Date: Sun, 14 Nov 1999 14:53:39 +0100
Subject: [Mailman-Developers] Giving Translation Help
Message-ID: <99111414561702.00618@abulafia.4net.it>

Hi from Italy

What is the best procedure to make a full italian translation for mailman
and to have it distributed within the next (I hope) release of mailman?

Thanks

-- 
    Simone Piunno,  http://pioppo.cjb.net,  simone@piunno.com
     Ferrara Linux Users Group  -->  http://ferrara.linux.it
      ICQ UIN: 6914669 pioppo@IRCnet on #ferrara, #linux-it 
GnuPG/PGP5 fp: 9C15 F0D3 E309 3593 AC95  2C92 A0CD 52B4 8603 14FC


From jcrey@uma.es  Mon Nov 15 08:19:28 1999
From: jcrey@uma.es (Juan Carlos Rey Anaya)
Date: Mon, 15 Nov 1999 09:19:28 +0100
Subject: [Mailman-Developers] Giving Translation Help
References: <99111414561702.00618@abulafia.4net.it>
Message-ID: <382FC210.D7D65A7E@uma.es>

Pioppo wrote:
> 
> What is the best procedure to make a full italian translation for mailman
> and to have it distributed within the next (I hope) release of mailman?
> 

The process of Mailman i18n is in progress and is not a public subject
(yet).
Please contact Victoriano.giralt@uma.es or with me for a detailed to-do
list.

Actually Mailman is translated to:
English :-)
Spanish and
German

You can see a FULLY operational version at (of course demo version until
it will be included in a final release):
http://joker.sci.uma.es/mailman/listinfo/test

Cheers
-- 
                          ___
                         / F \
                        [[[]]]]
                        ( O O )
   #----------------0000--(_)--0000---------------#
   |    Juan Carlos Rey Anaya (jcrey@uma.es)      |
   |      Servicio Central de informática         |
   |       Universidad de Málaga - España         |
   #----------------------------------------------#
   #      Solo se que cada vez se menos :-|       #
   #----------------------------------------------#


From Rick.Niess@usm.edu  Mon Nov 15 23:28:55 1999
From: Rick.Niess@usm.edu (Rick Niess)
Date: Mon, 15 Nov 1999 17:28:55 -0600 (CST)
Subject: [Mailman-Developers] Features requested...
Message-ID: <Pine.LNX.4.10.9911151607270.30676-100000@netserver3.otr.usm.edu>

Hi Everyone,

     I have a several ideas for features that may be of interest.  Their
implementation would certainly be to my benefit.  I've listed them below.

     FYI, I'm testing out Mailman as a replacement for my campus' existing
Majordomo setup.  If I can just get a few issued resolved, I think the
transition will go easily.

1) Please add an option so subscribers can elect to show only the username
part of their e-mail address in the subscriber list instead of the whole
thing (regardless of the @->" at " conversion).

2) In the section of the listinfo page where a user can subscribe to the
list in question, please add another radio-button option for "Conceal
yourself from subscriber list?" if the list's subscriber list can be seen
by the list members or the public.  I'm somewhat of an anti-spam nut so I
don't like having my e-mail address publically visible in any form.

3) Allow the system-wide admin to disable the mail->news and news->mail
gatewaying for the whole system and/or for selected lists. (I've got some
list admins that want to use this, but I *really* don't want to see that
kind of traffic on my server.  Not to mention the liability issues...)

4) On the membership management admin page, please setup a mechanism for
large lists to limit the display of user options to X number of users per
page.  It's a killer to try to admin large lists from slow machines with
limited memory. (ex, took me a long time and a lot of swapping to load the
page for a 3000 member list)

5) Please setup a means by which a user can specify what additional
addresses he/she posts from other than their subscription address. (For
example, my campus has a mail aliasing system so that all public addresses
have the form "firstname.lastname@usm.edu" or similar.  But the address
they post from may be "username@host.usm.edu" or similar.  This becomes a
problem for lists that have member_posting_only turned on.)

6) Please setup a mechanism for a pre-made set of options to be used
as defaults when creating new lists.  For instance, on our campus, we have
a form that prospective list owners fill out to request a new list.  On
this form, we have the following options for them to "check" that
determine how their list is initially setup.:

Archived list (Duh)
Closed list (Subscriptions requests must be approved list list owner.
             Otherwise list is "Open" and anyone may subscribe.)
Secured list (Only list members may post to the list)
Moderated list (list owner must approve all posts to the list)
Announcement (List will be used for outgoing announcements only.  Implies
              moderated and secured.)

I don't mind creating files with all of the configuration options and
their default config values.  I just need a snippet of code to read the
values in and use those as defaults when creating the list.  And then,
perhaps if I combined that with #7 below, I could get it to automatically
import the configuration of a previous majordomo list... (I don't know how
either of these would work with the idea to create lists from a site admin
page, tho.  Perhaps the site admin could choose from a pull-down menu of
option pre-sets or pre-existing majordomo lists when creating a mailman
list?)

7) If anyone has written a withlist module that can read in the values in
an existing Majordomo 1.94 config file and update the corrosponding values
in a Mailman list's config db, I'd be ever so greatful to get a copy. This
would make transitioning to mailman *so* much easier than having to do
each list by hand through the web interface.

8) The <body> tag is not currently setup right for error pages.

9) Please build-in the option for individual list owners to filter binary
attachments. (I think something like this is already in the works, but I'd
like it to be a per-list option settable by the list owner.)

10) In the pipermail archives, please do the following:

  - move the archives to http://host/mailman/archives/listname or provide
    a redirect from there to http://host/pipermail/listname.
  - implelement a link for users to reply to posts in an archive by using
    a mailto: URL to open up a mailer window from their browser.  Or
    perhaps make this optional on a per-list basis.
    (Note: this might break threading if a specific "In-Reply-to" header
     can't be added)
  - in threaded view:
     (a) add links at the bottom of each post to go back to the previous
         thread and forward to the next.
     (b) perhaps setup a mode where a user could see all the threads
         expanded on one page (as it is now) or see all the thread titles
         on one page and clicking them expands the thread into a new page.


     Lastly, I'd like to note that, while I understand most of what's
going on in the code, I don't have time ATM to sit down and really learn
Python.  Hence, I don't have the expertise to go about making most of
these modifications myself.  I do, however, plan to sit down and learn
Python as well as possible over the holiday break.  So perhaps I can pitch
in directly during the new year.

     Thank-you for your attention.  I look forward to hearing from anyone
who can help! ;-)

						~ Rick Niess ~
--
.oooO "Man with closed Oooo.    Rick C. Niess
(   )   mouth gathers  (   )    University of Southern Miss.
 \ (      no foot!"     ) /     guardian@bark.cc.usm.edu
--\_)------------------(_/-------------------------------







From jafo@tummy.com  Tue Nov 16 02:53:34 1999
From: jafo@tummy.com (Sean Reifschneider)
Date: Mon, 15 Nov 1999 19:53:34 -0700
Subject: [Mailman-Developers] Features requested...
In-Reply-To: <Pine.LNX.4.10.9911151607270.30676-100000@netserver3.otr.usm.edu>; from Rick Niess on Mon, Nov 15, 1999 at 05:28:55PM -0600
References: <Pine.LNX.4.10.9911151607270.30676-100000@netserver3.otr.usm.edu>
Message-ID: <19991115195334.C26336@tummy.com>

On Mon, Nov 15, 1999 at 05:28:55PM -0600, Rick Niess wrote:
>4) On the membership management admin page, please setup a mechanism for
>large lists to limit the display of user options to X number of users per
>page.  It's a killer to try to admin large lists from slow machines with

Hmm, it already does that.  When you select membership, it displays them
in chunks of 10 or something.  I've upped mine to 30, and would actually
prefer 100.

I do note that with my 1.0 install, if I log in with the site-admin
password, I can't select the broken-out lists (it asks for the password
again, then takes me back to the first chunk, even though it says
"chunk=3" or whatever in the URL.

>5) Please setup a means by which a user can specify what additional
>addresses he/she posts from other than their subscription address. (For
>example, my campus has a mail aliasing system so that all public addresses

The current way we're doing this is that if users have multiple addresses
they want to post from, they have to subscribe once for each of those
addresses, and then only enable delivery on ONE of them.

For you, it sounds like you may want to limit it to members only, but then
allow posting from anyone who's e-mail address is "*@usm.edu" or
"*@*.usm.edu"...  Not ideal, but it sounds like your environment doesn't
really keep users from having a new address every week, and that's hard
to predict.

>  - move the archives to http://host/mailman/archives/listname or provide
>    a redirect from there to http://host/pipermail/listname.

Correct me if I'm wrong, but can't you do that in Apache with a slightly
modified version of the lines you already have in there to get the
"/mailman/" and "/pipermail/" URLs to work?

>     Lastly, I'd like to note that, while I understand most of what's
>going on in the code, I don't have time ATM to sit down and really learn
                         ^^^^^^^^^^^^^^^^^^^

Yeah, that seems to be the common problem these days.  Too much demand,
too few geeks.

Sean
-- 
 "Where are we going?"  "Planet Ten!"  "When?"  "Real soon!"
                 -- _Buckaroo_Banzai_
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
URL: <http://www.tummy.com/xvscan> HP-UX/Linux/FreeBSD/BSDOS scanning software.


From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Tue Nov 16 03:39:01 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Mon, 15 Nov 1999 22:39:01 -0500 (EST)
Subject: [Mailman-Developers] Features requested...
References: <Pine.LNX.4.10.9911151607270.30676-100000@netserver3.otr.usm.edu>
Message-ID: <14384.53717.606487.837270@anthem.cnri.reston.va.us>

Sean responded to a bunch of Rick's points, and I'll just add a few
more thoughts.

>>>>> "RN" == Rick Niess <rniess@netserver3.otr.usm.edu> writes:

    RN> 1) Please add an option so subscribers can elect to show only
    RN> the username part of their e-mail address in the subscriber
    RN> list instead of the whole thing (regardless of the @->" at "
    RN> conversion).

The problem here is that we don't actually keep that information
around in the database.  This is bogus, and is something that I hope
will get fixed when we have a real User database (don't ask when ;)

    RN> 2) In the section of the listinfo page where a user can
    RN> subscribe to the list in question, please add another
    RN> radio-button option for "Conceal yourself from subscriber
    RN> list?"

I'd actually like to see more options at the subscription page, if not
all the options a user can change later (that might be too cluttered
and daunting though).

    RN> 3) Allow the system-wide admin to disable the mail->news and
    RN> news->mail gatewaying for the whole system and/or for selected
    RN> lists.

You can disable news->mail easily by shutting off the cron entry for
gate_news.  Shutting off mail->news will actually be much easier to
accomplish with the current CVS snapshot, since you can just edit out
the ToUsenet module from the message delivery pipeline.

There's a meta-issue about providing more site configuration options
via the Web, and that's definitely something I'd like to improve in
the future.

    RN> 5) Please setup a means by which a user can specify what
    RN> additional addresses he/she posts from other than their
    RN> subscription address. (For example, my campus has a mail
    RN> aliasing system so that all public addresses have the form
    RN> "firstname.lastname@usm.edu" or similar.  But the address they
    RN> post from may be "username@host.usm.edu" or similar.  This
    RN> becomes a problem for lists that have member_posting_only
    RN> turned on.)

Again, with a real User database, we could easily allow users to
subscribe multiple addresses, enabling delivery to some or all of
those addresses, and allowing postings from any of a User's known
addresses.  Very difficult to do right now unfortunately.

    RN> 6) Please setup a mechanism for a pre-made set of options to
    RN> be used as defaults when creating new lists.

I've thought about this, but haven't had time to work on it.  It
actually would be easy to do (contributions?? :).  Remember that
bin/newlist isn't magic -- it's really quite simple.  What you could
do is hack this script to include various common list "personalities",
which really just means certain list option settings, and then just
make those settings after the call to newlist.Create().

A simple hack would be to just have a bunch of classes in the newlist
script which implement these defaults, and add a command line switch
to invoke one of those classes on the newly created list.  If you want
to get fancy, you could publish an API and let folks add their own
list personalities.  newlist would try to import a module, dig a class
out, call the API method on the list object, and then Save it.
    
    RN> 7) If anyone has written a withlist module that can read in
    RN> the values in an existing Majordomo 1.94 config file and
    RN> update the corrosponding values in a Mailman list's config db,
    RN> I'd be ever so greatful to get a copy.

And if you do, please let me know, 'cause I'd love to add something
like this to the distribution!

    RN> 8) The <body> tag is not currently setup right for error
    RN> pages.

I don't understand; I guess you mean the driver script is broken?  Can
you give me more details?

    RN> 9) Please build-in the option for individual list owners to
    RN> filter binary attachments. (I think something like this is
    RN> already in the works, but I'd like it to be a per-list option
    RN> settable by the list owner.)

Again, while this functionality doesn't exist yet, the new message
delivery architecture could accomodate this much more easily.

    RN> 10) In the pipermail archives, please do the following:

I'd love it if someone became the Pipermail champion.  I just don't
have the wherewithal to do much development on this code.

    RN>      Lastly, I'd like to note that, while I understand most of
    RN> what's going on in the code, I don't have time ATM to sit down
    RN> and really learn Python.  Hence, I don't have the expertise to
    RN> go about making most of these modifications myself.  I do,
    RN> however, plan to sit down and learn Python as well as possible
    RN> over the holiday break.  So perhaps I can pitch in directly
    RN> during the new year.

Well Rick, it'll probably take you about a day to learn all the Python
you need to become a prolific Mailman hacker!  Just be sure to try it
/before/ you eat the turkey dinner and get all "stuffed". :)

-Barry


From cherub@azrael.dyn.cheapnet.net  Tue Nov 16 04:24:09 1999
From: cherub@azrael.dyn.cheapnet.net (Steven Hazel)
Date: Mon, 15 Nov 1999 22:24:09 -0600 (CST)
Subject: [Mailman-Developers] Features requested...
In-Reply-To: <14384.53717.606487.837270@anthem.cnri.reston.va.us>
 (bwarsaw@cnri.reston.va.us)
References: <Pine.LNX.4.10.9911151607270.30676-100000@netserver3.otr.usm.edu> <14384.53717.606487.837270@anthem.cnri.reston.va.us>
Message-ID: <m11naA5-0007SjC@azrael.dyn.cheapnet.net>

   The problem here is that we don't actually keep that information
   around in the database.  This is bogus, and is something that I hope
   will get fixed when we have a real User database (don't ask when ;)

What are the current plans for this?  I'd like to help.  I should have
some time over the coming holidays.

-S


From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Tue Nov 16 04:22:08 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Mon, 15 Nov 1999 23:22:08 -0500 (EST)
Subject: [Mailman-Developers] Digest #399
Message-ID: <14384.56304.891547.558006@anthem.cnri.reston.va.us>

Sorry folks, there was a bug in the new CalcRecips module that broke
the last digest delivery.  I think I've fixed it now but here's what
happened:

If you are a non-digest member, you erroneously got digest #399.
Sorry about that!

If you are a digest member you did not get digest #399.  Please check
the archives for the articles you missed.  Here's the list of
subjects:

  1. Changes working, and list moved (mailman-developers-admin@python.org)
  2. Changes working, and list moved (mailman-developers-admin@python.org)
  3. Changes working, and list moved (mailman-developers-admin@python.org)
  4. Changes working, and list moved (mailman-developers-admin@python.org)
  5. Changes working, and list moved (mailman-developers-admin@python.org)
  6. Changes working, and list moved (mailman-developers-admin@python.org)
  7. Changes working, and list moved (mailman-developers-admin@python.org)
  8. Re: Changes working, and list moved (Barry A. Warsaw)
  9. Re: Changes working, and list moved (Barry A. Warsaw)
  10. test from off-site (mailman-developers-admin@python.org)
  11. test #2 (mailman-developers-admin@python.org)
  12. Giving Translation Help (Pioppo)
  13. Re: Giving Translation Help (Juan Carlos Rey Anaya)
  14. Features requested... (Rick Niess)
  15. Re: Features requested... (Sean Reifschneider)
  16. Re: Features requested... (Barry A. Warsaw)

Ain't it fun being a guinea pig? :)

Sorry for any inconvenience...
-Barry


From bwarsaw@python.org  Tue Nov 16 04:56:56 1999
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 15 Nov 1999 23:56:56 -0500 (EST)
Subject: [Mailman-Developers] Features requested...
References: <Pine.LNX.4.10.9911151607270.30676-100000@netserver3.otr.usm.edu>
 <14384.53717.606487.837270@anthem.cnri.reston.va.us>
 <m11naA5-0007SjC@azrael.dyn.cheapnet.net>
Message-ID: <14384.58392.966859.375322@anthem.cnri.reston.va.us>

>>>>> "SH" == Steven Hazel <cherub@azrael.dyn.cheapnet.net> writes:

    Me>    The problem here is that we don't actually keep that
    Me> information around in the database.  This is bogus, and is
    Me> something that I hope will get fixed when we have a real User
    Me> database (don't ask when ;)

    SH> What are the current plans for this?  I'd like to help.  I
    SH> should have some time over the coming holidays.

Well, there are a number of questions (if it was an easy hack it'd
already be done :).

First, do we want to use a real OODB underneath (such as ZODB), or do
we cook our own?  If we cook our own, do we modify Mailman to run as a
long-running process to make things efficient?  How do we handle
safely modifying the user database (e.g. a user adding email addresses
to their profiles)?  There are also UI issues for making all this
convenient for users.  Finally, a user database should be robust
enough to handle specifying various other roles.  IOW, users can also
be list admins, list moderators, and site admins.

Too sleepy to write more tonight.

-Barry


From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Thu Nov 18 01:37:58 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Wed, 17 Nov 1999 20:37:58 -0500 (EST)
Subject: [Mailman-Developers] Re: [Mailman-Users] optimizing mail delivery
References: <3832B316.43C5FDAC@bcb.gov.br>
 <klaubert@bcb.gov.br>
 <E11oAim-0002Q9-00@under.eng.cp.net>
 <19991117144753.A17570@xcski.com>
Message-ID: <14387.22646.76313.150613@anthem.cnri.reston.va.us>

>>>>> "PT" == Paul Tomblin <ptomblin@xcski.com> writes:

    PT> Wrong.  Sendmail *does* do this for you.  If you have a bunch
    PT> of people on a list in random order, sendmail will work
    PT> through the list in order, but every time it connects to a
    PT> domain, it will send one message to *all* the members of the
    PT> list at that domain.  One of my most popular lists has at
    PT> least 30% of its subscribers at panix.com, and another 10% at
    PT> best.com.  When it was on majordomo, the entire list was
    PT> passed off to sendmail in one chunk.  Since one of the
    PT> panix.com people is first on the list, all the panixians got
    PT> their mail first, then a few more people, then all the people
    PT> at best.com, etc.  Now that I'm using mailman, and it's split
    PT> into 5 chunks, I've noticed that one of the chunks is all
    PT> panixians, which goes in one message to panix, and one of the
    PT> chunks is almost all bestians, which also goes in one message.

So do you think the Mailman way is better or worse?  I'm curious
because I'm trying to decide whether I should port Mailman 1.0's bulk
mailer code to the new message pipeline.

In the current 1.2 code base (available via the anonCVS), I os.popen()
sendmail[1] passing the entire recipient list on the command line,
then I pipe the message text to stdin and let the MTA do the rest.
There's one complication; if the length of the recipients list is
greater than a certain length (current 3000), I chop it up into
multiple popens, but I don't do any sorting of the recipient list.

The advantage I see of this is that sendmail can do it's thing
asychronously, without keeping the list object locked the entire
time.  The disadvantage is that Mailman is only aware of delivery
problems if the delivery bounces.

I could see trying to sort the recips on the domain name if the total
length is > 3000.  I can also see porting the local-smptd delivery
scheme of the current bulk mailer, but fixing some of the problems in
the 1.0 code base (and there are quite a few).  I'm leary though of
stepping on too much of the MTA's toes -- a good MTA should just do
the right thing.

Another alternative, which would be less work and delegates all
delivery to the MTA, is to just pump all the recips to the local smtpd
via smtplib.py.  The advantage here is that again we're MTA
independent, but the disadvantage is that Mailman's delivery is
synchronous with the smtpd.  We'd have to be very sure to unlock the
list object during this transaction (but watching out for race
conditions, locking again if failure status's are handled directly,
etc.)  More code, more opportunity for bugs.

Comments?

-Barry

[1] I actually don't use sendmail, I use postfix, but the code is
easily configured to use anything with a sendmail compatible command
line interface.


From ptomblin@xcski.com  Thu Nov 18 01:45:13 1999
From: ptomblin@xcski.com (Paul Tomblin)
Date: Wed, 17 Nov 1999 20:45:13 -0500
Subject: [Mailman-Developers] Re: [Mailman-Users] optimizing mail delivery
In-Reply-To: <14387.22646.76313.150613@anthem.cnri.reston.va.us>; from Barry A. Warsaw on Wed, Nov 17, 1999 at 08:37:58PM -0500
References: <3832B316.43C5FDAC@bcb.gov.br> <klaubert@bcb.gov.br> <E11oAim-0002Q9-00@under.eng.cp.net> <19991117144753.A17570@xcski.com> <14387.22646.76313.150613@anthem.cnri.reston.va.us>
Message-ID: <19991117204513.A1135@xcski.com>

Quoting Barry A. Warsaw (bwarsaw@cnri.reston.va.us):
> So do you think the Mailman way is better or worse?  I'm curious
> because I'm trying to decide whether I should port Mailman 1.0's bulk
> mailer code to the new message pipeline.

Personally, I think you should leave it to the MTA to make the decisions on
how to deliver the mail more efficiently.  Anybody who wants more parallelism
can find an MTA to do that.  And that leaves Mailman to concentrate on doing
the things it does well, rather than second guessing the MTA.

-- 
Paul Tomblin, not speaking for anybody.
SETI@Home:  Finally a *good* way to impress Jodie Foster
http://www.setiathome.ssl.berkeley.edu/


From claw@cp.net  Thu Nov 18 02:04:21 1999
From: claw@cp.net (J C Lawrence)
Date: Wed, 17 Nov 1999 18:04:21 -0800
Subject: [Mailman-Developers] Re: [Mailman-Users] optimizing mail delivery
In-Reply-To: Message from "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
 of "Wed, 17 Nov 1999 20:37:58 EST." <14387.22646.76313.150613@anthem.cnri.reston.va.us>
References: <3832B316.43C5FDAC@bcb.gov.br> <klaubert@bcb.gov.br> <E11oAim-0002Q9-00@under.eng.cp.net> <19991117144753.A17570@xcski.com>  <14387.22646.76313.150613@anthem.cnri.reston.va.us>
Message-ID: <E11oGvt-0004Z6-00@under.eng.cp.net>

On Wed, 17 Nov 1999 20:37:58 -0500 (EST) 
Barry A Warsaw <bwarsaw@cnri.reston.va.us> wrote:

> So do you think the Mailman way is better or worse?  I'm curious
> because I'm trying to decide whether I should port Mailman 1.0's
> bulk mailer code to the new message pipeline.

MailMan's current code is definitely in the "good enough"
category.  

> In the current 1.2 code base (available via the anonCVS), I
> os.popen() sendmail[1] passing the entire recipient list on the
> command line, then I pipe the message text to stdin and let the
> MTA do the rest.  There's one complication; if the length of the
> recipients list is greater than a certain length (current 3000), I
> chop it up into multiple popens, but I don't do any sorting of the
> recipient list.

My view is that appropriate and efficient handling of mail for
delivery is the domain of the MTA, and should not be the domain of
MUA's (in which camp MailMan sorta falls).  As such domain sorting
is pleasant, it really only acts to further bolster technically
lagging mail servers which are in need of new life anyways.

> The advantage I see of this is that sendmail can do it's thing
> asychronously, without keeping the list object locked the entire
> time.  The disadvantage is that Mailman is only aware of delivery
> problems if the delivery bounces.

Which of course requires a local MTA, which the current design
doesn't.

What actually needs to happen (presuming my current understanding of
the source is correct) is that the abstraction of MailMan's internal
mail queue needs to be finished.  Then, a mail broadcast attempt
would only stuff messages (cheaply) into the MailMan queue
mechanism, and then return, unlocking the list objects.  The queue
object of course can be lock free (lockless DB's aren't difficult)
and you then merely need to run a could of MailMan queue runners to
pipe it to the MTA.

One the messages are stuffed, you can then fork a queue runner,
which, if there are already sufficient queue runners immediately
dies.  If more queue runners are needed however, it proceeds to grab 
messages and stuff them at the MTA in the normal fashion over SMTP.

Note:  If you do this adding VERP support becomes a doddle.

> I'm leary though of stepping on too much of the MTA's toes -- a
> good MTA should just do the right thing.

This is perhaps the best point.  Spending time to further bolster
fading technologies when better services are freely available hardly 
seems worth it.  

> Another alternative, which would be less work and delegates all
> delivery to the MTA, is to just pump all the recips to the local
> smtpd via smtplib.py.  The advantage here is that again we're MTA
> independent, but the disadvantage is that Mailman's delivery is
> synchronous with the smtpd.  We'd have to be very sure to unlock
> the list object during this transaction (but watching out for race
> conditions, locking again if failure status's are handled
> directly, etc.)  More code, more opportunity for bugs.

No no no no no no.  MailMan oeprates asynchronously of the MTA, and
because as a list server it generates unusual loads in itself, it
cannot be subject to the perfoamcen vagaries of the MTA.

Consider the case I used to commonly run into:

  Message arrives and is delivered to MailMan.

  MailMan explodes that message into a couple thousand more messages 
  (100K+ subscribers).

  MailMan attempts to hand off messages to MTA.

  MTA refuses connections as system load is too high.

  MailMan bitches.

  Meanwhile another message arrives at MailMan to be exploded.

> Comments?

Nope!

-- 
J C Lawrence                              Internet: claw@kanga.nu
----------(*)                            Internet: coder@kanga.nu
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...


Return-Path: <owner-mailman-developers@python.org>
Delivered-To: mailman-developers@dinsdale.python.org
Received: from python.org (parrot.python.org [132.151.1.90])
	by dinsdale.python.org (Postfix) with ESMTP id 568F31CD3E
	for <mailman-developers@dinsdale.python.org>; Wed, 17 Nov 1999 21:14:51 -0500 (EST)
Received: from caesar.elte.hu (caesar.elte.hu [157.181.42.42])
	by python.org (8.9.1a/8.9.1) with ESMTP id VAA20080;
	Wed, 17 Nov 1999 21:14:48 -0500 (EST)
Received: from localhost (gorgo@localhost)
	by caesar.elte.hu (8.9.0/8.9.0) with SMTP id DAA50042;
	Thu, 18 Nov 1999 03:14:16 +0100
Date: Thu, 18 Nov 1999 03:14:15 +0100 (MET)
From: Gergely Madarasz <gorgo@caesar.elte.hu>
X-Sender: gorgo@caesar.power.elte.hu
To: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
Cc: Paul Tomblin <ptomblin@xcski.com>, J C Lawrence <claw@cp.net>,
	Klaubert Herr da Silveira <klaubert@bcb.gov.br>,
	mailman-users@python.org, mailman-developers@python.org
Subject: Re: [Mailman-Developers] Re: [Mailman-Users] optimizing mail delivery
In-Reply-To: <14387.22646.76313.150613@anthem.cnri.reston.va.us>
Message-ID: <Pine.A32.3.96.991118030855.28574H-100000@caesar.power.elte.hu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: mailman-developers-admin@python.org
Errors-To: mailman-developers-admin@python.org
X-BeenThere: mailman-developers@python.org
X-Mailman-Version: 1.1+
Precedence: bulk
List-Id: Mailman mailing list developers <mailman-developers.python.org>

On Wed, 17 Nov 1999, Barry A. Warsaw wrote:

> So do you think the Mailman way is better or worse?  I'm curious
> because I'm trying to decide whether I should port Mailman 1.0's bulk
> mailer code to the new message pipeline.

Actually I kinda like the mailman bulk mailer. Before I switched from
majordomo, I used an external bulkmail package (called from aliases, what
mailman doesn't do on delivery so I can't use it with mailman) to help out
sendmail. Changing MTA's on a high traffic site can be a real PITA, I
wouldn't like it if I had to change it because mailman can't help it out
anymore :( So I think it would be nice if you left it as an option.

-- 
Madarasz Gergely           gorgo@caesar.elte.hu         gorgo@linux.rulez.org
      It's practically impossible to look at a penguin and feel angry.
          Egy pingvinre gyakorlatilag lehetetlen haragosan nezni.
                    HuLUG: http://mlf.linux.rulez.org/



From dragondm@integral.org  Thu Nov 18 14:49:47 1999
From: dragondm@integral.org (The Dragon De Monsyne)
Date: Thu, 18 Nov 1999 08:49:47 -0600 (CST)
Subject: [Mailman-Developers] Re: [Mailman-Users] optimizing mail delivery
In-Reply-To: <14387.22646.76313.150613@anthem.cnri.reston.va.us>
Message-ID: <Pine.LNX.3.96.991118083727.15316B-100000@delta.integral.org>

On Wed, 17 Nov 1999, Barry A. Warsaw wrote:

> 
> Another alternative, which would be less work and delegates all
> delivery to the MTA, is to just pump all the recips to the local smtpd
> via smtplib.py.  The advantage here is that again we're MTA
> independent, but the disadvantage is that Mailman's delivery is
> synchronous with the smtpd.  We'd have to be very sure to unlock the
> list object during this transaction (but watching out for race
> conditions, locking again if failure status's are handled directly,
> etc.)  More code, more opportunity for bugs.

	In my own highly-hacked version of mailman that I use, I do this. 
Mailman simply drops outgoing messages into the queue directory. A
background daemon de-queues the messages and pumps them to the local MTA
via SMTP. A cronjob checks the  daemon periodically, and starts it if is
falls over. All very simple, and  has worked very reliably for me for
several months.

	-The Dragon De Monsyne



From Rick.Niess@usm.edu  Thu Nov 18 22:28:47 1999
From: Rick.Niess@usm.edu (Rick Niess)
Date: Thu, 18 Nov 1999 16:28:47 -0600 (CST)
Subject: [Mailman-Developers] Features requested...
In-Reply-To: <14384.53717.606487.837270@anthem.cnri.reston.va.us>
Message-ID: <Pine.LNX.4.10.9911181527590.30524-100000@netserver3.otr.usm.edu>

Hi All,

     Whew!  Sorry for the delay in response.  Been busybusybusy.  And
sick. <snifflesniffle> Getting better tho.  Anyway...

On Mon, 15 Nov 1999, Barry A. Warsaw wrote:
>     RN> subscribe to the list in question, please add another
>     RN> radio-button option for "Conceal yourself from subscriber
> I'd actually like to see more options at the subscription page, if not
> all the options a user can change later (that might be too cluttered
> and daunting though).

     <nod> I'd thought about asking for all of them but didn't want to
push my luck. ;-) Having "as many as is tactful and/or sensible in the
context" would be a good idea, IMHO.

>     RN> 3) Allow the system-wide admin to disable the mail->news and
>     RN> news->mail gatewaying for the whole system and/or for selected
> You can disable news->mail easily by shutting off the cron entry for
> gate_news.  Shutting off mail->news will actually be much easier to
> accomplish with the current CVS snapshot, since you can just edit out
> the ToUsenet module from the message delivery pipeline.

     <nod> I've already done this.  However, it doesn't remove the
configuration option from each list's admin pages.  But I think you knew
what I meant. ;-)

     BTW, from the sound of it, the new modular pipline structure Barry
described sounds like a winner! *lots* more flexibility. Even room for
on-the-fly user modules, etc.  One question, tho.  What was "CVS" mean?

>     RN> 5) Please setup a means by which a user can specify what
>     RN> additional addresses he/she posts from other than their
>     RN> subscription address. (For example, my campus has a mail
> Again, with a real User database, we could easily allow users to
> subscribe multiple addresses, enabling delivery to some or all of
> those addresses, and allowing postings from any of a User's known
> addresses.  Very difficult to do right now unfortunately.

     Yup.  Although I will note that Mailman's current means of dealing
with it (multiple subscriptions, only one actually delivering) is more
elegant than Majordomo's (just multiple subscriptions or a separate list
that doesn't actually handle posts)

>     RN> 6) Please setup a mechanism for a pre-made set of options to
>     RN> be used as defaults when creating new lists.
<snip>
> which really just means certain list option settings, and then just
> make those settings after the call to newlist.Create().
<snip>
> A simple hack would be to just have a bunch of classes in the newlist
> script which implement these defaults, and add a command line switch
> to invoke one of those classes on the newly created list.  If you want
> to get fancy, you could publish an API and let folks add their own
<snip>

     Oy.  OOP has never been my strong suit.  Okay, sticking with the KISS
principle, how about the desired initial "personalities" each be stored in
separate files all stored in a single subdirectory somewhere (ex,
"$prefix/personalities").  The format can be a simple
"maiman_db_variable_name='desired value'" on each line allowing for hashed
comment lines. Look familiar to some Majordomo users? <g> (Note: We'll
have to figure out a way to weed out erroneous input from here.) Then the
site admin can specify that personality with a command-line switch to
newlist.  And this could be handled right after newlist.Create(), as you
said.

     *And*, we could implement a separate switch to import a
Majordomo-style config file and map to the appropriate values, etc.  Not
hard, just tedious.  I'll be happy to sit down and write up a map of what
Majordomo values go to what Mailman values if someone can use this in the
short term...

>     RN> 8) The <body> tag is not currently setup right for error
>     RN> pages.
> I don't understand; I guess you mean the driver script is broken?  Can
> you give me more details?

     Sure.  All the normal admin and default user pages have a BODY tag
like '<BODY BGCOLOR="#ffffff">'.  But most of the erorr pages (ex, from
the archives and options CGI's) only have '<body>'.  Not terrible, just
cosmetic.  Then again, some of the error messages themselves could use a
little elaboration.  And uniformity. (Yes I know it's an opensource
project and, no, I'm not berating anyone.  Just pointing out the obvious
so it can be fixed at some point.)

>     RN>      Lastly, I'd like to note that, while I understand most of
>     RN> what's going on in the code, I don't have time ATM to sit down
>     RN> and really learn Python.  Hence, I don't have the expertise to
> Well Rick, it'll probably take you about a day to learn all the Python
> you need to become a prolific Mailman hacker!  Just be sure to try it
> /before/ you eat the turkey dinner and get all "stuffed". :)

     <giggle> We shall see... ;-) BTW, I should note that I have not
really dealt with OOP before. (That's one of the reasons Python seems so
daunting to me.) So if I've made some statments that don't make sense for
Python, now you know why.  Anyway, thanx for listening.

						~ Rick ~
--
.oooO "Man with closed Oooo.    Rick C. Niess
(   )   mouth gathers  (   )    University of Southern Miss.
 \ (      no foot!"     ) /     resnet@usm.edu
--\ )------------------(_/-------------------------------






From Rick.Niess@usm.edu  Thu Nov 18 23:11:35 1999
From: Rick.Niess@usm.edu (Rick Niess)
Date: Thu, 18 Nov 1999 17:11:35 -0600 (CST)
Subject: [Mailman-Developers] Features requested...
In-Reply-To: <19991115195334.C26336@tummy.com>
Message-ID: <Pine.LNX.4.10.9911181629160.30524-100000@netserver3.otr.usm.edu>

Hi All,

On Mon, 15 Nov 1999, Sean Reifschneider wrote:
> On Mon, Nov 15, 1999 at 05:28:55PM -0600, Rick Niess wrote:
> >4) On the membership management admin page, please setup a mechanism for
> >large lists to limit the display of user options to X number of users per
> >page.  It's a killer to try to admin large lists from slow machines with
> Hmm, it already does that.  When you select membership, it displays them
> in chunks of 10 or something.  I've upped mine to 30, and would actually
> prefer 100.

     I must have broken this somehow.  Checking into it...

> >5) Please setup a means by which a user can specify what additional
> >addresses he/she posts from other than their subscription address. (For
<snip>
> For you, it sounds like you may want to limit it to members only, but then
> allow posting from anyone who's e-mail address is "*@usm.edu" or
> "*@*.usm.edu"...  Not ideal, but it sounds like your environment doesn't
> really keep users from having a new address every week, and that's hard
> to predict.

     Ahh.  Very good points.  The latter isn't exactly feasable in a few
cases, but it's a start.

> >  - move the archives to http://host/mailman/archives/listname or provide
> >    a redirect from there to http://host/pipermail/listname.
> Correct me if I'm wrong, but can't you do that in Apache with a slightly
> modified version of the lines you already have in there to get the
> "/mailman/" and "/pipermail/" URLs to work?

     I hadn't thought of that.  Yes, it should work.  I've added a third
"Alias" line to Apache's srm.conf:

Alias /icons/ /home/httpd/icons/
Alias /pipermail/ /home/mailman/archives/public/
Alias /mailman/archives/ /home/mailman/archives/public/

     I left the old one in in case the change broke something.  As a side
note, I'll say that I was more concerned with URL uniformity than the
actual location of the archiver and data.

> >     Lastly, I'd like to note that, while I understand most of what's
> >going on in the code, I don't have time ATM to sit down and really learn
>                          ^^^^^^^^^^^^^^^^^^^
> Yeah, that seems to be the common problem these days.  Too much demand,
> too few geeks.

     Perhaps, but that's also why some of us are paid well. ;-)

						~ Rick ~
--
.oooO "Man with closed Oooo.    Rick C. Niess
(   )   mouth gathers  (   )    University of Southern Miss.
 \ (      no foot!"     ) /     resnet@usm.edu
--\ )------------------(_/-------------------------------






From andy@nachoz.com  Fri Nov 19 22:17:47 1999
From: andy@nachoz.com (Andy Harrison)
Date: Fri, 19 Nov 1999 17:17:47 -0500 (EST)
Subject: [Mailman-Developers] Feature suggestion
Message-ID: <XFMail.991119171747.andy@nachoz.com>

Just had an idea for a cool feature.  

I run a humor list and keep the filesize limit fairly low, most of the people
are dial-up of course.  I don't want to mail bomb a ton of people because
someone stupidly e-mailed the 3.2MB aliens_1.mpg file.  Right now, I pretty much
just reject it that's it.  

However, my idea is this.  What if there was some sort of mechanism in place
that stored the file in a different type of archive, and instead of mailing the
file, it included a link to click on to pick up the file instead.  That way they
could see the file size first and whatnot and know what they were getting into
before they tried to download it.


---------------------------------
E-Mail:  Andy Harrison <andy@nachoz.com>
Date:  19-Nov-99
Time:  16:46:19

This message was sent by XFMail
---------------------------------


From a.eyre@optichrome.com  Mon Nov 22 13:55:01 1999
From: a.eyre@optichrome.com (Adrian Eyre)
Date: Mon, 22 Nov 1999 13:55:01 -0000
Subject: [Mailman-Developers] Feature suggestion
In-Reply-To: <XFMail.991119171747.andy@nachoz.com>
Message-ID: <000701bf34f1$2bba3710$3acbd9c2@peridot.optichrome.com>

> However, my idea is this.  What if there was some sort of mechanism in
place
> that stored the file in a different type of archive, and instead of
mailing
> the file, it included a link to click on to pick up the file instead.

Good idea. Could it be generalised to allow all people on the mailing list
to specify a maximum attachment size. All attachments below this are
attached
to the e-mail, and any larger are replaced with links. Or maybe as a total
attachment size for each e-mail, rather than on an attachment by attachment
basis.

There is of course the issue of how long to retain the attachment on the
server
for people to pick up later. Could do it on a maximum meggage basis, and
remove
the oldest ones when space is needed for new ones.

--------------------------------------------
Adrian Eyre <mailto:a.eyre@optichrome.com>
Optichrome Computer Solutions Ltd
Maybury Road, Woking, Surrey, GU21 5HX, UK
Tel: +44 1483 740 233  Fax: +44 1483 760 644
http://www.optichrome.com
--------------------------------------------



From jmackenzie@local.ie  Mon Nov 22 14:32:40 1999
From: jmackenzie@local.ie (John MacKenzie)
Date: Mon, 22 Nov 1999 14:32:40 +0000
Subject: [Mailman-Developers] Mailman Taking on httpd UID & GID ????
In-Reply-To: <000701bf34f1$2bba3710$3acbd9c2@peridot.optichrome.com>
References: <000701bf34f1$2bba3710$3acbd9c2@peridot.optichrome.com>
Message-ID: <9911221436300C.26429@samsara.merrion.nua.net>

Hey Folks, 
I'm having a little bit of a problem, 

Having issues that when you change the config.db using the web config tool, it
writes it as UID & GID www.
Therefore Stopping mailman reading it.

I Checked a working server , and they were in the form of user : mailman/Root
Group Mailman.
permissions Being R/W R/W R.

On this machine they are user www , group www
and permissions are simply RW / RW
even if I chown and chmod the files back to normal, on next admin change, they
revert back to the above.

Any ideas?
regards
- John


-- 
John MacKenzie | Unix Systems Admin | e: mailto:jmackenzie@local.ie
___________________________________________________________________
Stay in touch your local area through Local Ireland
http://chat.local.ie/chat/index.html 
___________________________________________________________________
local ireland  | dublin  |  new york  |  http://www.local.ie



From secabeen@pobox.com  Mon Nov 22 16:24:23 1999
From: secabeen@pobox.com (Ted Cabeen)
Date: Mon, 22 Nov 1999 10:24:23 -0600
Subject: [Mailman-Developers] Missed Bounce Message
Message-ID: <199911221624.KAA27878@entropy.uchicago.edu>

Here's another missed bounce message.  

Can't SMTP server writers decide on a standard for bounces and just use it?  
Arrgh.

--
Ted Cabeen           http://www.pobox.com/~secabeen         secabeen@pobox.com
Check Website or finger for PGP Public Key        secabeen@midway.uchicago.edu
"I have taken all knowledge to be my province." -F. Bacon   cococabeen@aol.com
"Human kind cannot bear very much reality."-T.S.Eliot 73126.626@compuserve.com

------- Forwarded Message

Return-Path: ua-admin@lists.uchicago.edu
Delivery-Date: Mon Nov 22 08:23:36 1999
Return-Path: <ua-admin@lists.uchicago.edu>
Received: from einstein.uchicago.edu (einstein.uchicago.edu [128.135.132.24])
	by entropy.uchicago.edu (8.9.3/8.8.8) with ESMTP id IAA27074
	for <secabeen@entropy.uchicago.edu>; Mon, 22 Nov 1999 08:23:36 -0600 (CST)
Received: from growl.pobox.com (growl.pobox.com [208.210.124.27])
	by einstein.uchicago.edu (8.8.8+Sun/8.8.7) with ESMTP id IAA27870
	for <secabeen@control.uchicago.edu>; Mon, 22 Nov 1999 08:23:29 -0600 (CST)
Received: by growl.pobox.com (Postfix, from userid 15)
	id 0781B7EF2; Mon, 22 Nov 1999 09:23:29 -0500 (EST)
Received: from lists.uchicago.edu (lists.uchicago.edu [128.135.132.161])
	by growl.pobox.com (Postfix) with ESMTP id D09057EF2
	for <secabeen@pobox.com>; Mon, 22 Nov 1999 09:23:26 -0500 (EST)
Received: from lists (localhost [127.0.0.1])
	by lists.uchicago.edu (8.9.3/8.9.3) with ESMTP id OAA14807
	for <secabeen@pobox.com>; Mon, 22 Nov 1999 14:23:26 GMT
Received: from LEXECON.LEXECON.COM (mail.lexecon.com [199.99.121.201])
	by lists.uchicago.edu (8.9.3/8.9.3) with SMTP id OAA14781
	for <ua-admin@lists.uchicago.edu>; Mon, 22 Nov 1999 14:23:23 GMT
Message-Id: <199911221423.OAA14781@lists.uchicago.edu>
Date: Mon, 22 Nov 1999 08:22:05 CST
From: <SMTP@LEXECON.LEXECON.COM>
To: <ua-admin@lists.uchicago.edu>
Subject: Undeliverable Mail
Sender: ua-admin@lists.uchicago.edu

Attempting to deliver following mail to recipient(s):
    <brighoff@DominoFax.lexecon.com>
LEXECON.LEXECON.COM unable to connect for 1 days to recipient host.
Delivery will be attempted for a total of 3 days.

           ** Text of Mail follows **
Received: from lists.uchicago.edu [128.135.132.161] by LEXECON.LEXECON.COM (IBM VM SMTP Level 310) via TCP with SMTP ; Fri, 19 Nov 1999 20:24:31 CST
Received: from lists (localhost [127.0.0.1])
	by lists.uchicago.edu (8.9.3/8.9.3) with ESMTP id CAA08065;
	Sat, 20 Nov 1999 02:25:41 GMT
Received: from hme0.mailrouter01.sprint.ca (hme0.mailrouter01.sprint.ca [207.107.250.16])
	by lists.uchicago.edu (8.9.3/8.9.3) with ESMTP id CAA08037
	for <ua@lists.uchicago.edu>; Sat, 20 Nov 1999 02:25:36 GMT
Received: from [209.148.137.13] (spc-isp-wpg-uas-08-66.sprint.ca [209.148.137.13])
	by hme0.mailrouter01.sprint.ca (8.8.8/8.8.8) with ESMTP id VAA13278
	for <ua@lists.uchicago.edu>; Fri, 19 Nov 1999 21:25:30 -0500 (EST)
User-Agent: Microsoft Outlook Express Macintosh Edition - 5.0 (1513)
Date: Fri, 19 Nov 1999 20:25:36 -0600
Subject: Re: [UA] On the structure and arrangement of the occult
	underground
From: Rick Neal <grendel@sprint.ca>
To: <ua@lists.uchicago.edu>
Message-ID: <B45B62C0.26D%grendel@sprint.ca>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Reply-To: ua@lists.uchicago.edu
Sender: ua-admin@lists.uchicago.edu
Errors-To: ua-admin@lists.uchicago.edu
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: The Unknown Armies RPG Mailing List <ua.lists.uchicago.edu>
X-BeenThere: ua@lists.uchicago.edu

<snip>


--KAA27849.943287760/entropy.uchicago.edu--




From secabeen@pobox.com  Mon Nov 22 16:28:28 1999
From: secabeen@pobox.com (Ted Cabeen)
Date: Mon, 22 Nov 1999 10:28:28 -0600
Subject: [Mailman-Developers] Mailman Taking on httpd UID & GID ????
In-Reply-To: Your message of "Mon, 22 Nov 1999 14:32:40 GMT."
 <9911221436300C.26429@samsara.merrion.nua.net>
Message-ID: <199911221628.KAA27934@entropy.uchicago.edu>

In message <9911221436300C.26429@samsara.merrion.nua.net>, John MacKenzie write
s:
>Hey Folks, 
>Having issues that when you change the config.db using the web config tool, it
>writes it as UID & GID www.
>Therefore Stopping mailman reading it.

This is probably a permissions problem.  You probably need to turn on the 
setGID bit on all the directories under ~mailman and set the group to 
mailman.  Try running bin/check_perms and see what it comes up with.  If it 
reports incorrect permissions, bin/check_perms -f should fix them.

--
Ted Cabeen           http://www.pobox.com/~secabeen         secabeen@pobox.com
Check Website or finger for PGP Public Key        secabeen@midway.uchicago.edu
"I have taken all knowledge to be my province." -F. Bacon   cococabeen@aol.com
"Human kind cannot bear very much reality."-T.S.Eliot 73126.626@compuserve.com




From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Mon Nov 22 17:01:55 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Mon, 22 Nov 1999 12:01:55 -0500 (EST)
Subject: [Mailman-Developers] Missed Bounce Message
References: <199911221624.KAA27878@entropy.uchicago.edu>
Message-ID: <14393.30467.365346.646197@anthem.cnri.reston.va.us>

>>>>> "TC" == Ted Cabeen <secabeen@pobox.com> writes:

    TC> Here's another missed bounce message.

    TC> Can't SMTP server writers decide on a standard for bounces and
    TC> just use it?  Arrgh.

Heh, that would be nice wouldn't it?  Anyway, I'm going to convert
bounce processing to the same pipeline architecture I'm using for
message delivery.  This should allow us to easily extend for new
formats, as well as start us down the road of a test framework.

I've suddenly gotten slammed with a bunch of other stuff I have to do,
so we'll see how it goes.  Maybe I'll find some time to hack over
Tgiving...

-Barry


From richard@beenz.com  Mon Nov 22 17:45:08 1999
From: richard@beenz.com (Richard Leyton)
Date: Mon, 22 Nov 1999 17:45:08 +0000
Subject: [Mailman-Developers] Mailmerge?
Message-ID: <38398124.68C372A7@beenz.com>

Hi all,

Just wondered if anybody else out there has, or is, thinking about
support for mailmerge in the mailman software? It's something I need
from my mailing software (as well as support for a dynamic user list
drawn from a database), and I'm not keen on spending £lots if mailman
could be modified...

As you can tell from my mail address, I work at beenz.com, and we will
soon be needing to e-mail our user base occasional e-mails with details
of their balances and new offers. There's nothing really out there at
the moment beyond an inhouse script we've written that just about does
the job for small volumes. We're talking several hundred thousand mails
soon enough == problems!

Any comments/suggestions? I'm bracing myself to dip into the mailman
source code - but my experience with python is (at the moment, at least)
minimal, so before starting I thought I'd check whether you feel that
it's something the mailman architecture could support, and people would
want to see (besides myself!).

Looking forward to your comments.

Regards,

Richard.

--
Richard Leyton, Unix Systems Admin - http://www.beenz.com - The web's currency
mailto:richard@beenz.com





From mats@laplaza.org  Mon Nov 22 18:03:10 1999
From: mats@laplaza.org (Mats Wichmann)
Date: Mon, 22 Nov 1999 11:03:10 -0700
Subject: [Mailman-Developers] Feature suggestion
In-Reply-To: <000701bf34f1$2bba3710$3acbd9c2@peridot.optichrome.com>
References: <XFMail.991119171747.andy@nachoz.com>
Message-ID: <3.0.6.32.19991122110310.00e7cc50@laplaza.org>

At 01:55 PM 11/22/1999 -0000, Adrian Eyre wrote:
>> However, my idea is this.  What if there was some sort of mechanism in
>> place that stored the file in a different type of archive, and instead 
>> of mailing the file, it included a link to click on to pick up the file 
>> instead.
>
>Good idea. Could it be generalised to allow all people on the mailing list
>to specify a maximum attachment size. All attachments below this are
>attached to the e-mail, and any larger are replaced with links. Or maybe 
>as a total attachment size for each e-mail, rather than on an attachment 
>by attachment basis.

Sure seems like it would be a useful feature.  I'm mostly stuck
on very slow lines, many times it's a long-distance call to get
that much. I'd like to be able to defer getting attachments -
pretty much ALL attachments - until I know at least I've got a
toll-free connection, even if it's a slow one.  Maybe there's not
enough of us so "blessed" to be worth a change, though....



From richarde@eskom.co.za  Tue Nov 23 16:30:41 1999
From: richarde@eskom.co.za (Richard Ellerbrock)
Date: Tue, 23 Nov 1999 18:30:41 +0200
Subject: [Mailman-Developers] Bug in 1.1
Message-ID: <s83add5e.063@eskom.co.za>

Since upgrading to 1.1, I am getting the following error in my error log. =
I do not know when it occurs or what leads up to it.

Nov 23 10:44:16 1999 post: Traceback (innermost last):
post:   File "/home/mailman/scripts/mailowner", line 42, in ?
post:      mlist =3D MailList.MailList(sys.argv[1])
post:   File "/home/mailman/Mailman/MailList.py", line 62, in __init__
post:      self.Load()
post:   File "/home/mailman/Mailman/MailList.py", line 804, in Load
post:      self.Lock()
post:   File "/home/mailman/Mailman/MailList.py", line 1373, in Lock
post:      self.__lock.lock()
post:   File "/home/mailman/Mailman/LockFile.py", line 186, in lock
post:      os.link(self.__lockfile, self.__tmpfname)
post: os . error :  (2, 'No such file or directory')


--
Richard Ellerbrock
richarde@eskom.co.za



From richarde@eskom.co.za  Tue Nov 23 16:47:43 1999
From: richarde@eskom.co.za (Richard Ellerbrock)
Date: Tue, 23 Nov 1999 18:47:43 +0200
Subject: [Mailman-Developers] Bug in 1.1
Message-ID: <s83ae15f.037@eskom.co.za>

Ok, did that and found 1 error:

/home/mailman/data/adm.pw permissions must be exactly 0640 (got 0100644)
(fixing)
Problems found: 1

Will monitor. Thanks for the advice.

--
Richard Ellerbrock
richarde@eskom.co.za

>>> John MacKenzie <jmackenzie@local.ie> 1999/11/23 06:35:14 >>>
That looks rather like the error I was recieving when my files/folders =
where
the incorrect GId.
Try running bin/check_perms?
Regards
- John



On Tue, 23 Nov 1999, you wrote:
> Since upgrading to 1.1, I am getting the following error in my error =
log. I do not know when it occurs or what leads up to it.
>=20
> Nov 23 10:44:16 1999 post: Traceback (innermost last):
> post:   File "/home/mailman/scripts/mailowner", line 42, in ?
> post:      mlist =3D MailList.MailList(sys.argv[1])
> post:   File "/home/mailman/Mailman/MailList.py", line 62, in __init__
> post:      self.Load()
> post:   File "/home/mailman/Mailman/MailList.py", line 804, in Load
> post:      self.Lock()
> post:   File "/home/mailman/Mailman/MailList.py", line 1373, in Lock
> post:      self.__lock.lock()
> post:   File "/home/mailman/Mailman/LockFile.py", line 186, in lock
> post:      os.link(self.__lockfile, self.__tmpfname)
> post: os . error :  (2, 'No such file or directory')
>=20
>=20
> --
> Richard Ellerbrock
> richarde@eskom.co.za=20
>=20
>=20
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org=20
> http://www.python.org/mailman/listinfo/mailman-developers=20
--=20
John MacKenzie | Unix Systems Admin | e: mailto:jmackenzie@local.ie=20
___________________________________________________________________
Stay in touch your local area through Local Ireland
http://chat.local.ie/chat/index.html=20
___________________________________________________________________
local ireland  | dublin  |  new york  |  http://www.local.ie=20




From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Wed Nov 24 17:37:29 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Wed, 24 Nov 1999 12:37:29 -0500 (EST)
Subject: [Mailman-Developers] Another round of changes
Message-ID: <14396.8793.967096.320721@anthem.cnri.reston.va.us>

Hi folks,

I have another big batch of checkins ready to go.  This set of changes
should simplify the code even more; now all delivery of non-list email
(e.g. admin notifications, post rejections, etc.) go through their own
smaller message pipeline.  Gone are contact_transport, deliver, and
dumb_deliver scripts.  Messages snagged off a newsgroup now also go
through the pipeline directly.

The advantages are that tracing through the code is much much
simpler.  I've also tried to remove all unused code, although there
may be more simplification to follow.

The downside is that currently there's no direct SMTP delivery,
although I've started to hack together a module for the message
pipeline that will do this.  It may not be as elaborate as the bulk
mailer, but it will give us back MTA independence.  You'd be able to
select either Sendmail (command line) or SMTPDirect as your MTA
delivery mechanism, but for now, you'll have to that by hacking the
code.  Fortunately, there's one file you'd need to hack to change
this.

Once again, I'm going to do the checkin, followed by more local
testing.  If all looks good, I'll make you guys guinea pigs again :)
for some wider test.

Has anybody looked at the new stuff?  If so, are you using it, even
for test lists?

My goal (dream? nightmare?) is to migrate all of the Python.Org lists
over to the new software over the Thanksgiving weekend.  We shall
see...

-Barry


From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Wed Nov 24 22:33:10 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Wed, 24 Nov 1999 17:33:10 -0500 (EST)
Subject: [Mailman-Developers] Latest changes
Message-ID: <14396.26534.282250.808841@anthem.cnri.reston.va.us>

Hey folks, I've finished checking in my latest batch of changes.
At least the basic stuff seems to be working fine, as this message
will prove if you actually see it :)

I could be asking for trouble, but I plan on moving many of the lower
volume mailing list from python.org over to this new code base.  It'll
be very interesting to see if it performs better.  I'm crossing my
fingers that it's not worse!  Narrowing it down to causes will be a
little difficult because 1) it'll be running on a much faster machine;
2) it will be using a different MTA (not sendmail); 3) the new Mailman
codebase.

Enjoy, and for you US folks, have a happy holiday,
-Barry


From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Thu Nov 25 00:35:02 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Wed, 24 Nov 1999 19:35:02 -0500 (EST)
Subject: [Mailman-Developers] Mailmerge?
References: <38398124.68C372A7@beenz.com>
Message-ID: <14396.33846.53595.701705@anthem.cnri.reston.va.us>

>>>>> "RL" == Richard Leyton <richard@beenz.com> writes:

    RL> Just wondered if anybody else out there has, or is, thinking
    RL> about support for mailmerge in the mailman software?

First time I've heard of mailmerge.  What is it, and what does it do?
    
-Barry


From dan@feld.cvut.cz  Thu Nov 25 08:40:15 1999
From: dan@feld.cvut.cz (Dan Ohnesorg)
Date: Thu, 25 Nov 1999 09:40:15 +0100 (CET)
Subject: [Mailman-Developers] Mailmerge?
In-Reply-To: <14396.33846.53595.701705@anthem.cnri.reston.va.us>
Message-ID: <Pine.LNX.4.20.9911250935150.31977-100000@poli.feld.cvut.cz>

On Wed, 24 Nov 1999, Barry A. Warsaw wrote:

> 
> >>>>> "RL" == Richard Leyton <richard@beenz.com> writes:
> 
>     RL> Just wondered if anybody else out there has, or is, thinking
>     RL> about support for mailmerge in the mailman software?
> 
> First time I've heard of mailmerge.  What is it, and what does it do?

Mailmerge is WordStar's command, it means serial mail, or personally
customized mails. Somethink like:

Dear {first-name},

Your termin for interview is on {date-time}

and then merged aganinst database with many firstnames, addresses and
meetings termins. 

Generally somethink what no one listmanager on net does. And I think it is
far away from mailmans purpose.



cheers
dan



-- 
                    ________________________________________
DDDDDD             
DD   DD                Dan Ohnesorg, supervisor on POWER     
DD  OOOO               Dan@feld.cvut.cz
DD OODDOO              Dep. of Power Engineering
DDDDDD OO              CTU FEL Prague, Bohemia
   OO  OO              work: +420 2 24352785;+420 2 24972109
    OOOO               home: +420 311 679679;+420 311 679311
                    ________________________________________

Spatril jsem ji tak jak ji panbuh stvoril.
  A stal se ateistou.



From richard@beenz.com  Thu Nov 25 10:21:18 1999
From: richard@beenz.com (Richard Leyton)
Date: Thu, 25 Nov 1999 10:21:18 +0000
Subject: [Mailman-Developers] Mailmerge?
References: <Pine.LNX.4.20.9911250935150.31977-100000@poli.feld.cvut.cz>
Message-ID: <383D0D9E.5BE1D49A@beenz.com>

Dan Ohnesorg wrote:

> On Wed, 24 Nov 1999, Barry A. Warsaw wrote:
>
> > First time I've heard of mailmerge.  What is it, and what does it do?
>
> Mailmerge is WordStar's command, it means serial mail, or personally
> customized mails. Somethink like:
>
> Dear {first-name},
>

Exactly correct. The data can be merged in from some external source, such as
a database, or a nice user list appended with additional information in some
way.

> Generally somethink what no one listmanager on net does. And I think it is
> far away from mailmans purpose.

Listserv implements this, but it's very expensive (£20k ~= $36k), and doesn't
work on Solaris or Linux.

I'd agree that it's not part of a mailmanagers /core/ functionality, but it's
functionality that'd be useful for announcement/newsletter type mailing lists
(which I suspect constitute a fair proportion of mailmans user base) and for
supporting large user bases (such as ours).

Regards,

Richard.




--
Richard Leyton, Unix Systems Admin - http://www.beenz.com - The web's currency
mailto:richard@beenz.com





From Rick.Niess@usm.edu  Thu Nov 25 23:30:03 1999
From: Rick.Niess@usm.edu (Rick Niess)
Date: Thu, 25 Nov 1999 17:30:03 -0600 (CST)
Subject: [Mailman-Developers] Found a privacy loophole...
Message-ID: <Pine.LNX.4.10.9911251723390.24729-100000@netserver3.otr.usm.edu>

Hi All,

     I just noticed something.  I have some lists which are "private", so
they don't show up in the index of lists that listinfo generates. However,
if you follow the link to the "list admin overview page", it shows all the
list names.  Not terribly useful to the average web browser, but to
someone who knows about mailman...

						~ Rick ~
--
.oooO "Man with closed Oooo.    Rick C. Niess
(   )   mouth gathers  (   )    University of Southern Miss.
 \ (      no foot!"     ) /     resnet@usm.edu
--\ )------------------(_/-------------------------------




From root@theporch.com  Fri Nov 26 13:47:44 1999
From: root@theporch.com (Phillip Porch)
Date: Fri, 26 Nov 1999 07:47:44 -0600 (CST)
Subject: [Mailman-Developers] Bug in Mailman version 1.2 (experimental) (fwd)
Message-ID: <Pine.SC5.4.10.9911260746350.16281-100000@sco.theporch.com>

---------- Forwarded message ----------
Date: Fri, 26 Nov 1999 07:26:16 -0600
From: Phillip Porch <root@theporch.com>
To: root@theporch.com
Subject: Bug in Mailman version 1.2 (experimental)

Bug in Mailman version 1.2 (experimental)
Bug in Mailman version 1.2 (experimental)

We're sorry, we hit a bug!
If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! 

Traceback:


Traceback (innermost last):
  File "/home/mailman/scripts/driver", line 108, in run_main
    pkg = __import__('Mailman.Cgi', globals(), locals(), [scriptname])
  File "/home/mailman/Mailman/Cgi/listinfo.py", line 28, in ?
    from Mailman import MailList
  File "/home/mailman/Mailman/MailList.py", line 39, in ?
    from Mailman.MailCommandHandler import MailCommandHandler
  File "/home/mailman/Mailman/MailCommandHandler.py", line 64, in ?
    option_info = {'digest'  : 0,
AttributeError: AcknowledgePosts





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

Environment variables:
      Variable Value 
      DOCUMENT_ROOT  /home  
      SERVER_ADDR  207.234.31.38  
      HTTP_ACCEPT_ENCODING  gzip, deflate  
      SERVER_PORT  8080  
      PATH_TRANSLATED  /home/bapolicy  
      REMOTE_ADDR  207.234.31.43  
      HTTP_ACCEPT_LANGUAGE  en-us  
      GATEWAY_INTERFACE  CGI/1.1  
      SERVER_NAME  sco.theporch.com  
      TZ  CST6CDT  
      HTTP_USER_AGENT  Mozilla/4.0 (compatible; MSIE 5.01; Windows 98)  
      HTTP_ACCEPT  */*  
      REQUEST_URI  /mailman/listinfo/bapolicy  
      PATH  /usr/local/bin:/usr/local/kde/bin:/bin:/etc:/usr/bin:/tcb/bin:.  
      QUERY_STRING   
      SCRIPT_FILENAME  /home/mailman/cgi-bin/listinfo  
      PATH_INFO  /bapolicy  
      HTTP_HOST  www.theporch.com:8080  
      REQUEST_METHOD  GET  
      SERVER_SIGNATURE  Apache/1.3.9 Server at sco.theporch.com Port 8080 
      SCRIPT_NAME  /mailman/listinfo  
      SERVER_ADMIN  root@sco.theporch.com  
      SERVER_SOFTWARE  Apache/1.3.9 (Unix)  
      PYTHONPATH  /home/mailman  
      REMOTE_PORT  1080  
      SERVER_PROTOCOL  HTTP/1.1  
      HTTP_CONNECTION  Keep-Alive  





From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Fri Nov 26 15:13:57 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Fri, 26 Nov 1999 10:13:57 -0500 (EST)
Subject: [Mailman-Developers] Bug in Mailman version 1.2 (experimental) (fwd)
References: <Pine.SC5.4.10.9911260746350.16281-100000@sco.theporch.com>
Message-ID: <14398.41909.845674.829105@anthem.cnri.reston.va.us>

If you're using the latest CVS snapshot, be sure to re-run configure
before doing a "make install".  You can just run config.status if you
still have that around.  You need to regenerate Mailman/Defaults.py
from the Mailman/Defaults.py.in file.

-Barry


From bwarsaw@python.org  Fri Nov 26 23:27:31 1999
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Fri, 26 Nov 1999 18:27:31 -0500 (EST)
Subject: [Mailman-Developers] Re: [Mailman-Users] optimizing mail delivery
References: <14387.22646.76313.150613@anthem.cnri.reston.va.us>
 <Pine.LNX.3.96.991118083727.15316B-100000@delta.integral.org>
Message-ID: <14399.5987.612724.582341@anthem.cnri.reston.va.us>

    Dragon> 	In my own highly-hacked version of mailman that I use,
    Dragon> I do this.  Mailman simply drops outgoing messages into
    Dragon> the queue directory. A background daemon de-queues the
    Dragon> messages and pumps them to the local MTA via SMTP. A
    Dragon> cronjob checks the daemon periodically, and starts it if
    Dragon> is falls over. All very simple, and has worked very
    Dragon> reliably for me for several months.

This would make a nice addition to Mailman, and probably wouldn't be
hard to port to the new message pipeline model.  How'd you like to
look into that?

-Barry


From dragondm@integral.org  Sat Nov 27 10:36:55 1999
From: dragondm@integral.org (The Dragon De Monsyne)
Date: Sat, 27 Nov 1999 04:36:55 -0600 (CST)
Subject: [Mailman-Developers] Re: optimizing mail delivery
In-Reply-To: <14399.5987.612724.582341@anthem.cnri.reston.va.us>
Message-ID: <Pine.LNX.3.96.991127042426.30741A-100000@delta.integral.org>

On Fri, 26 Nov 1999, Barry A. Warsaw wrote:


>     Dragon> 	In my own highly-hacked version of mailman that I use,
>     Dragon> I do this.  Mailman simply drops outgoing messages into
>     Dragon> the queue directory. A background daemon de-queues the
>     Dragon> messages and pumps them to the local MTA via SMTP. A
>     Dragon> cronjob checks the daemon periodically, and starts it if
>     Dragon> is falls over. All very simple, and has worked very
>     Dragon> reliably for me for several months.
> 
> This would make a nice addition to Mailman, and probably wouldn't be
> hard to port to the new message pipeline model.  How'd you like to
> look into that?

	Sure! I'd be happy to. Probably not today, as I have a rather bad
case of the flu, and right at the moment sitting upright for any length
of time is rewarded with nausea and a blinding headache :P,  but mebbe on
sunday I'll be up to it & I'll pull the CVS and see what I can do. It
should  be fairly simple to port. 

PS: good job for doing this cleanup, this is something that's been needed
for awhile.

	-The Dragon De Monsyne



From petrilli@amber.org  Sat Nov 27 14:40:42 1999
From: petrilli@amber.org (Christopher Petrilli)
Date: Sat, 27 Nov 1999 09:40:42 -0500
Subject: [Mailman-Developers] Mailmerge?
In-Reply-To: <383D0D9E.5BE1D49A@beenz.com>; from richard@beenz.com on Thu, Nov 25, 1999 at 10:21:18AM +0000
References: <Pine.LNX.4.20.9911250935150.31977-100000@poli.feld.cvut.cz> <383D0D9E.5BE1D49A@beenz.com>
Message-ID: <19991127094042.A11461@trump.amber.org>

Richard Leyton [richard@beenz.com] wrote:
> Dan Ohnesorg wrote:
> 
> > On Wed, 24 Nov 1999, Barry A. Warsaw wrote:
> >
> > > First time I've heard of mailmerge.  What is it, and what does it do?
> >
> > Mailmerge is WordStar's command, it means serial mail, or personally
> > customized mails. Somethink like:
> >
> > Dear {first-name},
> >
> 
> Exactly correct. The data can be merged in from some external source, such as
> a database, or a nice user list appended with additional information in some
> way.

I suspect that this would be nearly impossible unless you were merging in
pieces of information that Mailman already had... otherwise you'd have a huge
data corrolation piece.  ONe day, Mailman will actually have a more real
database behind it that lets you keep arbitrary data about each person, rather
than just their email.

Chris
-- 
| Christopher Petrilli
| petrilli@amber.org


From claw@kanga.nu  Mon Nov 29 04:19:40 1999
From: claw@kanga.nu (claw@kanga.nu)
Date: Sun, 28 Nov 1999 20:19:40 -0800
Subject: [Mailman-Developers] Mailman, hard links and the Openwall (fw)
Message-ID: <E11sIHs-0005NJ-00@koala.kanga.nu>

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <20661.943849179.1@kanga.nu>

This seems a little offbeat, but should be addressed:

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


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

X-Envelope-From: debian-devel-request@lists.debian.org Sun Nov 28 13:59:43 1999
Return-path: <debian-devel-request@lists.debian.org>
Envelope-to: claw@localhost
Delivery-date: Sun, 28 Nov 1999 13:59:43 -0800
Received: from localhost ([127.0.0.1] ident=claw)
	by koala.kanga.nu with esmtp (Exim 2.12 #1)
	id 11sCMB-00048o-00
	for claw@localhost; Sun, 28 Nov 1999 13:59:43 -0800
Received: from kanga.nu
	by fetchmail-4.5.8 POP3
	for <claw/localhost> (single-drop); Sun, 28 Nov 1999 13:59:43 PST
Received: from murphy.debian.org [209.41.108.199] 
	by kanga.nu with smtp (Exim 3.03 #1 (Debian))
	id 11sCOl-0004fJ-00; Sun, 28 Nov 1999 14:02:23 -0800
Received: (qmail 12190 invoked by uid 38); 28 Nov 1999 22:01:22 -0000
Resent-Date: 28 Nov 1999 22:01:22 -0000
Resent-Cc: recipient list not shown: ;
X-Envelope-Sender: grendel@vip.net.pl
Date: Sun, 28 Nov 1999 23:01:30 +0100
From: Marek Habersack <grendel@vip.net.pl>
To: debian-devel@lists.debian.org
Subject: Mailman, hard links and the Openwall
Message-ID: <19991128230130.A20329@vip.net.pl>
Reply-To: grendel@vip.net.pl
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
	protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE"
User-Agent: Mutt/1.0i
Organization: I just...
Resent-Message-ID: <PxjSiD.A.M-C.xYaQ4@murphy>
Resent-From: debian-devel@lists.debian.org
X-Mailing-List: <debian-devel@lists.debian.org> archive/latest/50197
X-Loop: debian-devel@lists.debian.org
Precedence: list
Resent-Sender: debian-devel-request@lists.debian.org


--Kj7319i9nmIyA2yE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Hi *,

  Some of you probably know the Solar Designer's OpenWall security patches
to the Linux kernel. One of the features of these patches is the ability to
prevent users from creating symlinks and hardlinks in /tmp to files they
don't own. Some time ago my Mailman stopped working and I didn't associate
the security warning messages popping up on a screen with the Solar
Designer's patch which I have just applied to the 2.2.13 kernle. Recently,
however, I decided to look at what might be the problem causing Mailman to
fail. It turns out that Mailman uses hard links in /tmp to files in the
/var/lib/mailman/lists/listname/* files and also to lock some other files.
The problem is that those files are owned by root.list with mode 664
(mostly) and the httpd daemon (Roxen in my case) runs the Mailman scripts as
nobody or list. The Solar Designer's code refuses creating sym- and
hardlinks to those files and Python raises an exception causing Mailman to
abort. Now, I see no reason for the files to be owned by root.list - after
making the httpd execute Mailman scripts with UID 38 (list) and changing the
ownership of the entire Mailman director tree to list.list everything
started to work smoothly again. Therefore, I think the postinst Mailman
script should change the ownership of the files to list.list.
 =20
thanks,

marek

--Kj7319i9nmIyA2yE
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEAREBAAYFAjhBpjoACgkQq3909GIf5urX8wCghi0X0FVGOGG4a9DCtQo3UIoh
g3QAn1DJByzpbwqXBfdLYfc79Fd9I79I
=7QYb
-----END PGP SIGNATURE-----

--Kj7319i9nmIyA2yE--


-- 
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



------- =_aaaaaaaaaa0--


From Rick.Niess@usm.edu  Thu Nov 25 23:30:03 1999
From: Rick.Niess@usm.edu (Rick Niess)
Date: Thu, 25 Nov 1999 17:30:03 -0600 (CST)
Subject: [Mailman-Developers] Found a privacy loophole...
Message-ID: <Pine.LNX.4.10.9911251723390.24729-100000@netserver3.otr.usm.edu>

Hi All,

     I just noticed something.  I have some lists which are "private", so
they don't show up in the index of lists that listinfo generates. However,
if you follow the link to the "list admin overview page", it shows all the
list names.  Not terribly useful to the average web browser, but to
someone who knows about mailman...

						~ Rick ~
--
.oooO "Man with closed Oooo.    Rick C. Niess
(   )   mouth gathers  (   )    University of Southern Miss.
 \ (      no foot!"     ) /     resnet@usm.edu
--\ )------------------(_/-------------------------------





From claw@kanga.nu  Mon Nov 29 06:34:18 1999
From: claw@kanga.nu (claw@kanga.nu)
Date: Sun, 28 Nov 1999 22:34:18 -0800
Subject: [Mailman-Developers] Found a privacy loophole...
In-Reply-To: Message from Rick Niess <rniess@netserver3.otr.usm.edu>
 of "Thu, 25 Nov 1999 17:30:03 CST." <Pine.LNX.4.10.9911251723390.24729-100000@netserver3.otr.usm.edu>
Message-ID: <E11sKOB-0005el-00@koala.kanga.nu>

On Thu, 25 Nov 1999 17:30:03 -0600 (CST) 
Rick Niess <rniess@netserver3.otr.usm.edu> wrote:

> Hi All, I just noticed something.  I have some lists which are
> "private", so they don't show up in the index of lists that
> listinfo generates. However, if you follow the link to the "list
> admin overview page", it shows all the list names.  Not terribly
> useful to the average web browser, but to someone who knows about
> mailman...

The most they can find out from the admin page without a list
password is the fact that a name exists and thereby the knowledge of
how to send administration and attempted post messages to the list.

If that is a problem, then you have larger problems in that you are
implicitly relying on security thru obscurity.  There is nothing
that that web page can tell anybody that someone merely watching the
mail traffic in and out of your site can't also determine.

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From fil@bok.net  Mon Nov 29 11:17:12 1999
From: fil@bok.net (Fil)
Date: Mon, 29 Nov 1999 12:17:12 +0100 (MET)
Subject: [Mailman-Developers] no passord on subscription page ... and others
Message-ID: <Pine.LNX.3.96.991129120802.978A-100000@orwell>

Hi mailman developers,

it seems to me that to request a password from the subscribing page is
confusing, overkill, and useless... when you can generate the password on
the fly for the user. So the patch would be in Mailman/Cgi/subscribe.py

>>>>>>>>>>>>>>>>>>>>>>>>>>
    if not form.has_key("pw") or not form.has_key("pw-conf"):
#################################### patch  fil@bok.net 27/11/1999
        pw  = Utils.MakeRandomPassword()
        pwc = pw
#        error = 1
#        results = (results
#             + "You must supply a valid password, and confirm it.<br>")
<<<<<<<<<<<<<<<<<<<<<<<<<<<

and one would have to modify the standard HTML template too. But maybe
this could be toggled from the list-admin page ?

Secondly: is it possible that the mail-command analyzer catches messages
sent to the list-on@server and list-off@server addresses and processes
them as subscribe/unsubscribe commands ?  This would emulate the LetterRip
behaviour (www.fogcity.com), which is quite nice in this respect.

Thirdly: I'd like people to be unsubscribed w/o their password. Some users
tend to be annoying when then want to leave.

Fourthly: I'm trying to see how to add a user-name field in the
subscribers database... seems alot of work. Is this a planned feature ?


Well, that's all for now; keep on the good work!



From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Mon Nov 29 19:52:15 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Mon, 29 Nov 1999 14:52:15 -0500 (EST)
Subject: [Mailman-Developers] Mailman, hard links and the Openwall (fw)
References: <E11sIHs-0005NJ-00@koala.kanga.nu>
Message-ID: <14402.55663.805571.378280@anthem.cnri.reston.va.us>

>>>>> "claw" ==   <claw@kanga.nu> writes:

    claw> This seems a little offbeat, but should be addressed:

README.LINUX hints at a similar issue.  Would someone with more direct
experience please rewrite or extend README.LINUX to describe what
someone with the OpenWall security patches ought to do?

Thanks,
-Barry


From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Mon Nov 29 20:08:50 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Mon, 29 Nov 1999 15:08:50 -0500 (EST)
Subject: [Mailman-Developers] no passord on subscription page ... and others
References: <Pine.LNX.3.96.991129120802.978A-100000@orwell>
Message-ID: <14402.56658.739390.667156@anthem.cnri.reston.va.us>

>>>>> "F" == Fil  <fil@bok.net> writes:

    F> it seems to me that to request a password from the subscribing
    F> page is confusing, overkill, and useless... when you can
    F> generate the password on the fly for the user. So the patch
    F> would be in Mailman/Cgi/subscribe.py

I'd rather make the password field optional, and generate a password
for them if it's missing.  In this case, you'd have to force a welcome
message so that the user will receive the password.

    F> Secondly: is it possible that the mail-command analyzer catches
    F> messages sent to the list-on@server and list-off@server
    F> addresses and processes them as subscribe/unsubscribe commands
    F> ?  This would emulate the LetterRip behaviour
    F> (www.fogcity.com), which is quite nice in this respect.

This probably wouldn't be hard to add, although I like list-add@
and list-remove@ or some such.

-Barry


From claw@kanga.nu  Mon Nov 29 20:20:34 1999
From: claw@kanga.nu (claw@kanga.nu)
Date: Mon, 29 Nov 1999 12:20:34 -0800
Subject: [Mailman-Developers] no passord on subscription page ... and others
In-Reply-To: Message from Fil <fil@bok.net>
 of "Mon, 29 Nov 1999 12:17:12 +0100." <Pine.LNX.3.96.991129120802.978A-100000@orwell>
Message-ID: <E11sXHm-0006lr-00@koala.kanga.nu>

On Mon, 29 Nov 1999 12:17:12 +0100 (MET) 
Fil  <fil@bok.net> wrote:

> it seems to me that to request a password from the subscribing
> page is confusing, overkill, and useless... when you can generate
> the password on the fly for the user. 

Many users like to control their passwords and so wish to select
them themselves (usually so that they can use the same password in
many places, but that's another matter).  Using this patch forces
such users to subscribe, confirm their subscription and _then_ go
log in with their assigned password to change it to their
preference.  

I don't see the point in being that righteous about what other
people use for their passwords.

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From jam@jamux.com  Mon Nov 29 23:33:03 1999
From: jam@jamux.com (John A. Martin)
Date: Mon, 29 Nov 1999 18:33:03 -0500
Subject: [Mailman-Developers] Nick Rout: RE: WebMail/WebAdmin can run on Postfix ?
Message-ID: <19991129233306.ED410481C@athene.jamux.com>

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

Name clash?

	jam

- ------- Forwarded Message

From: Nick Rout <nickr@ihug.co.nz>
To: "postfix-users@postfix.org" <postfix-users@postfix.org>
Subject: RE: WebMail/WebAdmin can run on Postfix ?
Date: Tue, 30 Nov 1999 09:11:41 +1300

There is Endymion mail man http://www.endymion.com/products/mailman/ . My 
isp (www.ihug.co.nz) uses it to give their users web based access to pop 
email, if thats what u are after. requires perl & cgi. Its not free however 
:-)

[[ ... ]]

- ------- End of Forwarded Message

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: By Mailcrypt 3.5.4 and Gnu Privacy Guard <http://www.gnupg.org/>

iD8DBQE4Qw0iUEvv1b/iXy8RAhJLAJ46sYZuw6p1IShbN/5KCZjMnUCYzgCeKaxt
KUUEyDHhRKZ00J6LQG7SONA=
=QY6p
-----END PGP SIGNATURE-----


From lindsey@ncsa.uiuc.edu  Mon Nov 29 23:43:06 1999
From: lindsey@ncsa.uiuc.edu (Christopher Lindsey)
Date: Mon, 29 Nov 1999 17:43:06 -0600 (CST)
Subject: [Mailman-Developers] Nick Rout: RE: WebMail/WebAdmin can run on Postfix ?
In-Reply-To: <19991129233306.ED410481C@athene.jamux.com> from "John A. Martin" at Nov 29, 99 06:33:03 pm
Message-ID: <199911292343.RAA14375@ferret.ncsa.uiuc.edu>

> Name clash?

Yes, but no...  :)

http://dinsdale.python.org/pipermail/mailman-users/1998-November/002888.html

Chris

> From: Nick Rout <nickr@ihug.co.nz>
> 
> There is Endymion mail man http://www.endymion.com/products/mailman/ . My 
> isp (www.ihug.co.nz) uses it to give their users web based access to pop 
> email, if thats what u are after. requires perl & cgi. Its not free however 


From ricardo@miss-janet.com  Mon Nov 29 20:59:33 1999
From: ricardo@miss-janet.com (Ricardo Kustner)
Date: Mon, 29 Nov 1999 21:59:33 +0100
Subject: [Mailman-Developers] thoughts on http+smtp
Message-ID: <19991129215933.G501@miss-janet.com>

Hi,

First of all, I mentioned this on this list earlier but back then I didnt
get much response so I'm trying it again, now the list seems a bit more
active :)
Anyway, i'm running mailman on a P100 with 64mb... even though that isn't
much compared to today's hardware... it still suffies for most of the needs
(for example, apache is running smoothly on it with quite many hits... with peeks
of 5,000 hits/hour ...there's a mysql server on it too.. handling most of those
requests through auth_mysql).
To get to the point, mailman is the best mailinglist software i found
so far, but one thing that still kinda bothers me sinds the beginning
is that when using the admin pages to approved messages which are held
for approval, the python cgi scripts won't finnish the http request
untill all messages have been feed to the MTA... i'm running a list
with 1,500+ subscribers and when about 20 messages are being approved
at the same time, that means the server will get a huge load in a short
period of time. Also, since the cgi script doesn't finnish untill the
messages have been submitted to the MTA, sometimes the http request
just times out... I personally think that a cgi script do his work
*quickly* and finnish outputting the html asap...
I think it would be great if the admindb.py could just 'mark' messages
to be delivered and a background process handles the dirty work, instead
of having cgi scripts doing the SMTP connections...
and i still vote for having mail, which is held for approval, in a seperate
directory instead of putting them in a python database...
well these are just some thoughts, i hope can start some discussion on it :)

Ricardo.

--



From ricardo@miss-janet.com  Mon Nov 29 21:08:10 1999
From: ricardo@miss-janet.com (Ricardo Kustner)
Date: Mon, 29 Nov 1999 22:08:10 +0100
Subject: [Mailman-Developers] Missed Bounce Message
In-Reply-To: <199911221624.KAA27878@entropy.uchicago.edu>; from secabeen@pobox.com on Mon, Nov 22, 1999 at 10:24:23AM -0600
References: <199911221624.KAA27878@entropy.uchicago.edu>
Message-ID: <19991129220810.H501@miss-janet.com>

On Mon, Nov 22, 1999 at 10:24:23AM -0600, Ted Cabeen wrote:
> Here's another missed bounce message.  
> Can't SMTP server writers decide on a standard for bounces and just use it?  
> Arrgh.
tell me about it... i've spend too many hours in my life trying to unsubscribe
list members who were bouncing their mail... going on a holiday is out of the
question of you are the owner of a mailinglist ;)
i don't understand why it seems that with all the standards on the internet,
nobody seems to have tried to set a standard on bouncing email (AFAIK)... every new
MTA creates his own exotic version... not mentioning the fact that some
mailers (AOL,hotmail) seem to have several different variations of bouncing
mail...
*sigh* i had to get that off my back :)

Ricardo.

--



From claw@kanga.nu  Tue Nov 30 01:30:13 1999
From: claw@kanga.nu (claw@kanga.nu)
Date: Mon, 29 Nov 1999 17:30:13 -0800
Subject: [Mailman-Developers] Missed Bounce Message
In-Reply-To: Message from Ricardo Kustner <ricardo@miss-janet.com>
 of "Mon, 29 Nov 1999 22:08:10 +0100." <19991129220810.H501@miss-janet.com>
Message-ID: <E11sc7S-0004Eh-00@koala.kanga.nu>

On Mon, 29 Nov 1999 22:08:10 +0100 
Ricardo Kustner <ricardo@miss-janet.com> wrote:

> On Mon, Nov 22, 1999 at 10:24:23AM -0600, Ted Cabeen wrote:
>> Here's another missed bounce message.  Can't SMTP server writers
>> decide on a standard for bounces and just use it?  Arrgh.

> tell me about it... 

As there is no standard format for bounce messages, and even if
there were one we'd still be suffering with non-standard ones due to 
the great many legacy MTAs as well as the many sites with locally
customised bounce messages, another approach is needed.

The most commonly recommended solution is VERP.  The problem with
VERP is that it places a very high load on the local MTA as well as
any distribution management you may have set up (eg domain routing).
The approach I took back when I was writing my own mailing list
server was a middle ground with the intent of avoiding most of
VERP's bandwidth concerns while retaining many of its advantages:

  The list server emitted messages in bundles of 100 RCPT TOs in the
  normal manner except for every Nth message.

  For every N'th message (and this encluded digests), that message
was sent individually to every subscriber with a custom header field
added.

The custom header field was ala:

  x-bounce-detect: ListMgr <listname> <subscriber_address> <count> <score>

Where 'count' was just a number that incremented every time N rolled
around.  It was used to detect how old this bounce was and if there
had been any other "bounce-sensitive" messages emitted since that
one was received.  The 'score' value was just a tracking value
indicating how close that subscriber was to being unsubscribed.

The intent was that the custom header could be found in the copy of
the original email encluded in the bounce message, and could be
easily analysed to find the name of the list, the original
subscriber's address (in case of the message being forwarded),
etc. I then just scanned bounce messages for the header, and kept
track of how often and rapidly each subscriber bounced messages, and 
if the rate exceeded a certain value, unsubscribing that member.

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From fil@bok.net  Tue Nov 30 08:32:01 1999
From: fil@bok.net (Fil)
Date: Tue, 30 Nov 1999 09:32:01 +0100 (MET)
Subject: [Mailman-Developers] no passord on subscription page ... and others
In-Reply-To: <E11sXHm-0006lr-00@koala.kanga.nu>
Message-ID: <Pine.LNX.3.96.991130092943.17377A-100000@orwell>

On Mon, 29 Nov 1999 claw@kanga.nu wrote:
> On Mon, 29 Nov 1999 12:17:12 +0100 (MET) 
> Fil  <fil@bok.net> wrote:
> 
> > it seems to me that to request a password from the subscribing
> > page is confusing, overkill, and useless... when you can generate
> > the password on the fly for the user. 
> 
> Many users like to control their passwords and so wish to select
> them themselves (usually so that they can use the same password in
> many places, but that's another matter).  Using this patch forces
> such users to subscribe, confirm their subscription and _then_ go
> log in with their assigned password to change it to their
> preference.  
> 
> I don't see the point in being that righteous about what other
> people use for their passwords.

No. I don'(t care what people use for their password; I just mean that the
password in this case is not that important, and to put it up front like
it is now can lead to : 
a) people giving their POP password
b) people being deterred from subscribing by the apparent complexity and
the burden of having to remember a new password





From fil@bok.net  Tue Nov 30 08:38:39 1999
From: fil@bok.net (Fil)
Date: Tue, 30 Nov 1999 09:38:39 +0100 (MET)
Subject: [Mailman-Developers] no passord on subscription page ... and others
In-Reply-To: <14402.56658.739390.667156@anthem.cnri.reston.va.us>
Message-ID: <Pine.LNX.3.96.991130093817.17377B-100000@orwell>

On Mon, 29 Nov 1999, Barry A. Warsaw wrote:
> >>>>> "F" == Fil  <fil@bok.net> writes:
> 
>     F> it seems to me that to request a password from the subscribing
>     F> page is confusing, overkill, and useless... when you can
>     F> generate the password on the fly for the user. So the patch
>     F> would be in Mailman/Cgi/subscribe.py
> 
> I'd rather make the password field optional, and generate a password
> for them if it's missing.  In this case, you'd have to force a welcome
> message so that the user will receive the password.

Yes this would be great

>     F> Secondly: is it possible that the mail-command analyzer catches
>     F> messages sent to the list-on@server and list-off@server
>     F> addresses and processes them as subscribe/unsubscribe commands
>     F> ?  This would emulate the LetterRip behaviour
>     F> (www.fogcity.com), which is quite nice in this respect.
> 
> This probably wouldn't be hard to add, although I like list-add@
> and list-remove@ or some such.

Fine with me ;)



From a.eyre@optichrome.com  Tue Nov 30 09:55:38 1999
From: a.eyre@optichrome.com (Adrian Eyre)
Date: Tue, 30 Nov 1999 09:55:38 -0000
Subject: [Mailman-Developers] NT Port
Message-ID: <001401bf3b19$0dd75420$3acbd9c2@peridot.optichrome.com>

Is there, or is anyone working on an NT port of Mailman?
If not, I may start working on one myself.

--------------------------------------------
Adrian Eyre <mailto:a.eyre@optichrome.com>
Optichrome Computer Solutions Ltd
Maybury Road, Woking, Surrey, GU21 5HX, UK
Tel: +44 1483 740 233  Fax: +44 1483 760 644
http://www.optichrome.com 
--------------------------------------------



From Rick.Niess@usm.edu  Tue Nov 30 16:39:08 1999
From: Rick.Niess@usm.edu (Rick Niess)
Date: Tue, 30 Nov 1999 10:39:08 -0600 (CST)
Subject: [Mailman-Developers] Found a privacy loophole...
In-Reply-To: <E11sKOB-0005el-00@koala.kanga.nu>
Message-ID: <Pine.LNX.4.10.9911301030020.27149-100000@netserver3.otr.usm.edu>

On Sun, 28 Nov 1999 claw@kanga.nu wrote:
> On Thu, 25 Nov 1999 17:30:03 -0600 (CST) 
> Rick Niess <rniess@netserver3.otr.usm.edu> wrote:
> > Hi All, I just noticed something.  I have some lists which are
> > "private", so they don't show up in the index of lists that
> > listinfo generates. However, if you follow the link to the "list
> > admin overview page", it shows all the list names.  Not terribly
> The most they can find out from the admin page without a list
> password is the fact that a name exists and thereby the knowledge of
> how to send administration and attempted post messages to the list.

     Whoah.  All I was pointing out was that attempting to hide the
existence of a list to those viewing the listinfo index (by turning off
the Advertize option) isn't entirely bulletproof.  The listinfo index page
specifically tells them how to get to the pages for lists that they know
exist but aren't listed there, and then it provides a link to the list
admin overview page which lists all existing lists, hidden or not.

     This isn't serious, or at least not on a system-wide level.  Just
possibly embarrasing to a list admin.  And Barry has already noted that
it's a known bug.  FYI...

						~ Rick ~
--
.oooO "Man with closed Oooo.    Rick C. Niess
(   )   mouth gathers  (   )    University of Southern Miss.
 \ (      no foot!"     ) /     resnet@usm.edu
--\ )------------------(_/-------------------------------




From secabeen@pobox.com  Tue Nov 30 18:08:24 1999
From: secabeen@pobox.com (Ted Cabeen)
Date: Tue, 30 Nov 1999 12:08:24 -0600
Subject: [Mailman-Developers] Found a privacy loophole...
In-Reply-To: Your message of "Tue, 30 Nov 1999 10:39:08 CST."
 <Pine.LNX.4.10.9911301030020.27149-100000@netserver3.otr.usm.edu>
Message-ID: <199911301808.MAA22790@entropy.uchicago.edu>

In message <Pine.LNX.4.10.9911301030020.27149-100000@netserver3.otr.usm.edu>, R
ick Niess writes:
>     Whoah.  All I was pointing out was that attempting to hide the
>existence of a list to those viewing the listinfo index (by turning off
>the Advertize option) isn't entirely bulletproof.  The listinfo index page
>specifically tells them how to get to the pages for lists that they know
>exist but aren't listed there, and then it provides a link to the list
>admin overview page which lists all existing lists, hidden or not.

Are you sure that your site works that way?  If a list is unadvertised, 
then it shouldn't show up on either the listinfo or admin pages.  Are you 
really seeing all the lists on the server on the admin page?  

--
Ted Cabeen           http://www.pobox.com/~secabeen         secabeen@pobox.com
Check Website or finger for PGP Public Key        secabeen@midway.uchicago.edu
"I have taken all knowledge to be my province." -F. Bacon   cococabeen@aol.com
"Human kind cannot bear very much reality."-T.S.Eliot 73126.626@compuserve.com




From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Tue Nov 30 21:09:21 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Tue, 30 Nov 1999 16:09:21 -0500 (EST)
Subject: [Mailman-Developers] Missed Bounce Message
References: <ricardo@miss-janet.com>
 <19991129220810.H501@miss-janet.com>
 <E11sc7S-0004Eh-00@koala.kanga.nu>
Message-ID: <14404.15617.893406.135943@anthem.cnri.reston.va.us>

>>>>> "claw" ==   <claw@kanga.nu> writes:

    claw> As there is no standard format for bounce messages, and even
    claw> if there were one we'd still be suffering with non-standard
    claw> ones due to the great many legacy MTAs as well as the many
    claw> sites with locally customised bounce messages, another
    claw> approach is needed.

Well, there is DSN, but you're essentially right since most MTA don't
seem to do DSN at all.  I think there's even some controversy over the
complexity of DSN bounce formats, so you're essentially left with a
plethora of formats that you have to parse.

    claw> The most commonly recommended solution is VERP.  The problem
    claw> with VERP is that it places a very high load on the local
    claw> MTA as well as any distribution management you may have set
    claw> up (eg domain routing).  The approach I took back when I was
    claw> writing my own mailing list server was a middle ground with
    claw> the intent of avoiding most of VERP's bandwidth concerns
    claw> while retaining many of its advantages:

For a while now I've been thinking that we could do this kind of
VERP-like custom messages for the password reminders.  Those we
already have to craft specially for each recipient, so why not include
an easily detected header, then catch those bounces and scan them?

-Barry


From jfesler@gigo.com  Tue Nov 30 21:29:57 1999
From: jfesler@gigo.com (jfesler@gigo.com)
Date: Tue, 30 Nov 1999 13:29:57 -0800 (PST)
Subject: [Mailman-Developers] Missed Bounce Message
In-Reply-To: <14404.15617.893406.135943@anthem.cnri.reston.va.us>
Message-ID: <Pine.BSF.4.10.9911301328400.36918-100000@heaven.gigo.com>

> For a while now I've been thinking that we could do this kind of
> VERP-like custom messages for the password reminders.  Those we
> already have to craft specially for each recipient, so why not include
> an easily detected header, then catch those bounces and scan them?

Note that some mail servers refuse to send the message body back (grrr).
If you do it as the envelope you're guaranteed to be able to recognize it,
whether or not the body bounces..

[I'm also highly in favor of the at-password-time bounce checking - keeps
load light-ish for most list traffic, and just the occasional
reminder/probe]




From claw@kanga.nu  Tue Nov 30 21:38:10 1999
From: claw@kanga.nu (claw@kanga.nu)
Date: Tue, 30 Nov 1999 13:38:10 -0800
Subject: [Mailman-Developers] Missed Bounce Message
In-Reply-To: Message from "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
 of "Tue, 30 Nov 1999 16:09:21 EST." <14404.15617.893406.135943@anthem.cnri.reston.va.us>
Message-ID: <E11suyQ-0008RU-00@koala.kanga.nu>

On Tue, 30 Nov 1999 16:09:21 -0500 (EST) 
Barry A Warsaw <bwarsaw@cnri.reston.va.us> wrote:

> For a while now I've been thinking that we could do this kind of
> VERP-like custom messages for the password reminders.  Those we
> already have to craft specially for each recipient, so why not
> include an easily detected header, then catch those bounces and
> scan them?

Not a bad idea at all!

I chose a selectable VERP-ish window as I wanted to be able to
tailor the sensitivity to the normal rate of list traffic: It
wouldn't be surprising to get 10 bounces a day from one member if
your post averages a couple hundred posts a day and you dine one
VERP-ish per 10 messages...

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From jafo@tummy.com  Tue Nov 30 21:50:02 1999
From: jafo@tummy.com (Sean Reifschneider)
Date: Tue, 30 Nov 1999 14:50:02 -0700
Subject: [Mailman-Developers] Missed Bounce Message
In-Reply-To: <Pine.BSF.4.10.9911301328400.36918-100000@heaven.gigo.com>; from jfesler@gigo.com on Tue, Nov 30, 1999 at 01:29:57PM -0800
References: <14404.15617.893406.135943@anthem.cnri.reston.va.us> <Pine.BSF.4.10.9911301328400.36918-100000@heaven.gigo.com>
Message-ID: <19991130145001.F989@tummy.com>

On Tue, Nov 30, 1999 at 01:29:57PM -0800, jfesler@gigo.com wrote:
>[I'm also highly in favor of the at-password-time bounce checking - keeps
>load light-ish for most list traffic, and just the occasional
>reminder/probe]

Yeah, that sounds like a good idea, but are you going to kick them off after
one bounce, or wait several months before kicking them off?  Or would a
failure of that message cause probes to begin being sent, or the address
to be marked as "suspect" and use VERPs for delivery?

I'm imagining something like a binary search.  You *CAN* use a header or
VERP while still sending batches, you just have to realize that a VERP
is associated with a particular SET of addresses.  You mark these as
suspect, and future deliveries to these addresses aren't batched.
The back-off time on these addresses being marked as suspect can be
relatively low, but probably should be by number of messages sent, not
by hours (for low volume lists).  Maybe 3 messages or less.

So, if you have three addresses bouncing from among 10k addresses, and
your chunk size is 20, you only send out about an extra 150 messages
to determin exactly where the bounce is.

This seems more efficient than sending probes regularly (particularly for
huge lists), and more pro-active than waiting till the end of the month.

I'd be interested in working on such a thing.  My question though is,
what's the preferred way to do this?  A header line (which may be
truncated by some MTAs), a unique envelope sender (which requires some
support from the *LOCAL* MTA, and qmail and sendmail do it differently)?

Sean
-- 
 Her eyes were like two brown circles with big black dots in the center.
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
URL: <http://www.tummy.com/xvscan> HP-UX/Linux/FreeBSD/BSDOS scanning software.


From claw@kanga.nu  Tue Nov 30 22:26:43 1999
From: claw@kanga.nu (claw@kanga.nu)
Date: Tue, 30 Nov 1999 14:26:43 -0800
Subject: [Mailman-Developers] Missed Bounce Message
In-Reply-To: Message from jfesler@gigo.com
 of "Tue, 30 Nov 1999 13:29:57 PST." <Pine.BSF.4.10.9911301328400.36918-100000@heaven.gigo.com>
Message-ID: <E11svjP-00002i-00@koala.kanga.nu>

On Tue, 30 Nov 1999 13:29:57 -0800 (PST) 
jfesler  <jfesler@gigo.com> wrote:

> Note that some mail servers refuse to send the message body back
> (grrr).  

I've found that the ones that don't at least send the headers are
few and far between (tho they do exist).

> If you do it as the envelope you're guaranteed to be able to
> recognize it, whether or not the body bounces..

True.

> [I'm also highly in favor of the at-password-time bounce checking
> - keeps load light-ish for most list traffic, and just the
> occasional reminder/probe]

As I mentioned to Barry, I opted for once every N messages where N
was configurable on a per-list basis.  This allowed some lists to be 
set trigger happy, and others lackadasical -- as befitted their
character and daily traffic loads.

Hurm.

My headers were:

  X-SubscriberData: subscr_address on <listname> #<lists's_bounce_count>"

The algorithm was:

  There were three configurable values per list: How often to issue
bounce messages: Every N days or M messages, whichever came the
sooner (no mail days genereated no bounce test messages), and a
sensitivity value.

  A bounced message was worth Q points, where Q was determined as
follows:

  To be removed from the list a member had to accrue a sufficiently
high bounce score.  The more rapidly he bounced messages the more
rapidly his score grew.  Gaps in bounces (is some bounce some don't,
and the score grows more slowly.

  Loosely, a mamber had to bounce every bounce_message for
<sensitivity> days with the bounce messages making it back to the
list server within 24 hours to be unsubscribed.

  This was done by calculating a bounce_score as follows:

    If the bounce message has the same bounce_count as the last
bounce-sensitive message issued (plus or minus one), then
<sensitivity> is added to the score.

    If the bounc message is from an older bounce-test, then
<sensitivity> - <age> - 1 is added to the score.

    If the bounce message is older than <sensitivity> days, then the
score is set to zero.

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Tue Nov 30 23:25:45 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Tue, 30 Nov 1999 18:25:45 -0500 (EST)
Subject: [Mailman-Developers] NT Port
References: <001401bf3b19$0dd75420$3acbd9c2@peridot.optichrome.com>
Message-ID: <14404.23801.728773.883739@anthem.cnri.reston.va.us>

>>>>> "AE" == Adrian Eyre <a.eyre@optichrome.com> writes:

    AE> Is there, or is anyone working on an NT port of Mailman?
    AE> If not, I may start working on one myself.

No one that I know of.  There have been some ideas floated on this
list in the past (search the archives at
http://www.python.org/search).

Good luck!
-Barry


From richarde@eskom.co.za  Mon Nov  1 13:56:48 1999
From: richarde@eskom.co.za (Richard Ellerbrock)
Date: Mon, 01 Nov 1999 15:56:48 +0200
Subject: [Mailman-Developers] Patch against sync_members
Message-ID: <s81db84c.043@eskom.co.za>

Here is a little patch against the sync_members program to allow it to understand the following syntax:

sync_members -w=no -a=no -f - listname

The sync members command did not understand the - filename (read from stdio), even though the help for sync_members says that it does read from stdio.

--- sync_members        Mon Nov  1 15:51:51 1999
+++ sync_members.eskom  Mon Nov  1 15:30:48 1999
@@ -166,6 +166,11 @@
         filemembers = fp.readlines()
         fp.close()
 
+#        filemembers = sys.argv[i:]
+        # if there were no arguments on the command line, then it's probably
+        # a user error.  XXX this is questionable
+#        if not filemembers:
+#            usage(1, 'No addresses found on the command line')
     else:
         try:
             fp = open(filename)


--
Richard Ellerbrock
richarde@eskom.co.za



From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Sat Nov  6 05:15:06 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Sat, 6 Nov 1999 00:15:06 -0500 (EST)
Subject: [Mailman-Developers] Announcing Mailman 1.1
Message-ID: <14371.47450.186806.711568@anthem.cnri.reston.va.us>

I have just uploaded Mailman version 1.1 to www.list.org, and this
will hopefully soon be mirrored to ftp.gnu.org.  This release is
precipitated by the removal of all GIFs from the distribution.  There
have also been some performance improvements, although lots more can
still be done. ;)

See the NEWS file excerpt below for details of changes.  Sadly, the
internationalization effort has not yet been integrated (mostly due to
time constraints of the core maintainers).

Mailman, the GNU mailing list manager, is software to help manage
email discussion lists, much like Majordomo and Smartmail.  Unlike
most similar products, Mailman gives each mailing list a web page, and
allows users to subscribe, unsubscribe, etc. over the web.  Even the
list manager can administer his or her list entirely from the web.
Mailman also integrates most things people want to do with mailing
lists, including archiving, mail-to-news gateways, and so on.  Mailman
is writtein primarily in Python, with a little bit of C for security.

See http://www.list.org or
http://www.gnu.org/software/mailman/mailman.html for details and
downloading.

-Barry

-------------------- snip snip --------------------
- All GIFs removed.  See http://www.gnu.org/philosophy/gif.html for
  the reason why.

- Improvements to the Pipermail archiver which make things faster.
  Primary change is that the .txt files are not gzip'd on every posted
  message.  Instead, use the new cron script `nightly_gzip' to gzip
  the .txt file in batches (this means that the .txt file will lag
  behind the on-line archives a little).

- From the C drivers programs, Python is invoked with the -S option.
  This tells Python to avoid importing the site module, which can
  improve start up time of the Python process considerably.  Note that
  the command line script invocation has not been changed.

- New configuration variables PUBLIC_EXTERNAL_ARCHIVER and
  PRIVATE_EXTERNAL_ARCHIVER which can contain a shell command string
  for os.popen().  This can be used to invoke an external archiver
  instead of the bundled Pipermail archiver.  See Defaults.py for
  details.

- new script `bin/find_member' which can be used to search for a
  member by regular expression.

- More child processes are reaped, which should eliminate most
  occurances of zombie processes.

- A few small miscellaneous bug fixes (including PR#99, PR#107) and
  improvements to the file locking algorithms.
-------------------- snip snip --------------------

<p><a href="http://www.list.org/">Mailman 1.1</a> - the GNU mailing
list manager, implemented primarily in Python.  (05-Nov-1999)


From gorgo@caesar.elte.hu  Sat Nov  6 13:16:13 1999
From: gorgo@caesar.elte.hu (Gergely Madarasz)
Date: Sat, 6 Nov 1999 14:16:13 +0100 (MET)
Subject: [Mailman-Developers] Announcing Mailman 1.1
In-Reply-To: <14371.47450.186806.711568@anthem.cnri.reston.va.us>
Message-ID: <Pine.A32.3.96.991106141519.33077c-100000@caesar.power.elte.hu>

On Sat, 6 Nov 1999, Barry A. Warsaw wrote:

> 
> I have just uploaded Mailman version 1.1 to www.list.org, and this
> will hopefully soon be mirrored to ftp.gnu.org.  This release is
> precipitated by the removal of all GIFs from the distribution.  There
> have also been some performance improvements, although lots more can
> still be done. ;)

Ugh... just in time to be included in debian potato before freeze :)

-- 
Madarasz Gergely           gorgo@caesar.elte.hu         gorgo@linux.rulez.org
      It's practically impossible to look at a penguin and feel angry.
          Egy pingvinre gyakorlatilag lehetetlen haragosan nezni.
                    HuLUG: http://mlf.linux.rulez.org/



From grin@tolna.net  Mon Nov  8 02:10:55 1999
From: grin@tolna.net (Peter Gervai)
Date: Mon, 8 Nov 1999 03:10:55 +0100
Subject: [Mailman-Developers] running on nice
Message-ID: <19991108031055.T29543@mail.tolna.net>

Hello,

I got angry at mailman/python eating up my resources all the time,
so I have put some 

os.nice(10) 

into deliver,post and mailcmd scripts. Maybe others would find this
appealing and would worth a configurable variable somewhere.

bye,
grin


From richarde@eskom.co.za  Mon Nov  8 13:44:59 1999
From: richarde@eskom.co.za (Richard Ellerbrock)
Date: Mon, 08 Nov 1999 15:44:59 +0200
Subject: [Mailman-Developers] ABEND: problem with sync_members command
Message-ID: <s826f003.067@eskom.co.za>

When I want to sync a huge list of e-mail addresses into a mailing list, I get the following ABEND:

[root@lisa bin]# /home/mailman/bin/sync_members -w=no -a=no -f /tmp/tt test
Traceback (innermost last):
  File "/home/mailman/bin/sync_members", line 257, in ?
    main()
  File "/home/mailman/bin/sync_members", line 239, in main
    mlist.ApprovedAddMember(addr, pw, digest, welcome, notifyadmin)
  File "/home/mailman/Mailman/MailList.py", line 944, in ApprovedAddMember
    raise e, v
Mailman.Errors.MMBadEmailError
[root@lisa bin]# 

This is with Mailman 1.1 freshly downloaded. sync_members does not complain about any invalid addresses. The number of addresses that I want to sync are over 3000! Could this be a problem?

--
Richard Ellerbrock
richarde@eskom.co.za



From jafo@tummy.com  Mon Nov  8 18:45:18 1999
From: jafo@tummy.com (Sean Reifschneider)
Date: Mon, 8 Nov 1999 11:45:18 -0700
Subject: [Mailman-Developers] ABEND: problem with sync_members command
In-Reply-To: <s826f003.067@eskom.co.za>; from Richard Ellerbrock on Mon, Nov 08, 1999 at 03:44:59PM +0200
References: <s826f003.067@eskom.co.za>
Message-ID: <19991108114518.F2540@tummy.com>

On Mon, Nov 08, 1999 at 03:44:59PM +0200, Richard Ellerbrock wrote:
>This is with Mailman 1.1 freshly downloaded. sync_members does not
>complain about any invalid addresses. The number of addresses that I
>want to sync are over 3000! Could this be a problem?

I don't know, but last week I created a new list and freshly inserted over
3000 addresses into it with no problems.

Sean
-- 
 "Engineering Tablets?  Does that mean if I swallow one, I'll be an engineer?"
                 -- Evelyn Mitchell
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
URL: <http://www.tummy.com/xvscan> HP-UX/Linux/FreeBSD/BSDOS scanning software.


From Luyin Zhao" <lzhao@cse.unl.edu  Tue Nov  9 02:53:05 1999
From: Luyin Zhao" <lzhao@cse.unl.edu (Luyin Zhao)
Date: Mon, 8 Nov 1999 20:53:05 -0600
Subject: [Mailman-Developers] Questionnaire For My Project
Message-ID: <027401bf2a5d$8e3dc080$c781d6ab@luyinzha>

This is a multi-part message in MIME format.

------=_NextPart_000_0271_01BF2A2B.411F64C0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable

Dear Mailman,
     I'm a graduate student (computer science) in University=20
of Nebraska-Lincoln. The Questionnaire for open source testing=20
below is for a paper I'm working on. Hope you can spend=20
five minutes to finish it in your busy time. Any of your=20
effort will be greatly appreciated!
Luyin
=20
Questionnaire for Open Source Testing
****************************************************
1. What programming language is used in developing your product
"Mailman 1.1":?
****************************************************
2. How many developers were involved in your project?
****************************************************
3. When do you begin to do testing?=20
    a. Requirement Analysis Phase=20
    b. Functional design Phase=20
    c. Internal Design Phase=20
    d. Implementation Phase=20
    e. After Implementation=20
    Note: Functional design is to describe the features of a system from
      technique-oriented perspective compared with the user-oriented=20
      perspective of requirement analysis. Internal design is to model=20
      the implementation of system, such as class diagrams.
Answer:
****************************************************
4. The time you spent in testing compared with the total time of =
development?
    a. <20%  b. 20%-40%  c. 40%-60%  d. 60-80%  e. >80%
Answer:
****************************************************
5. How do you prepare for your testing (using plan or schedule)?=20
    a. Written plan which was modified several times =20
    b. One plan draft without further modification =20
    c. I prepare it in my brain =20
    d. I have no plan
Answer:
****************************************************
6. Do you inspect the following items?
    a. Requirement Documentation (if you have) =20
    b. Design Documentation (if you have) =20
    c. Source code (besides relying on compiler and program execution to =

find faults in code)
Answer:
****************************************************
7. There are some defects resulted from the unclear definition of =
requirements.
   In the total defects of this category you found, approximately what=20
   percentage were found in code inspections, in unit tests and in =
system=20
   tests, respectively?
   a. <20%  b. 20%-40%  c. 40%-60%  d. 60-80%  e. >80%   f. Not =
applicable
Answer:     ,       ,    =20
****************************************************
8. The percent of time you spent in document inspection (compared with =
total=20
   development time) is:
    a. <20%  b. 20%-40%  c. 40%-60%  d. 60-80%  e. >80%   f. Not =
applicable
Answer:
****************************************************
9. How many people did you ask to check your documents or source code?
   Do you think it is useful?
    a. No =20
    b. A little bit =20
    c. Useful but not necessary =20
    d. They found lots of defects that I haven=92t found =20
    e. Absolutely necessary
Answer:
****************************************************
10. Do you use testing tools during your development? The name of it?
Answer:
****************************************************
11. What is the basis of your testing?
    a. Test whether system implemented what user need =20
    b. Test whether system implemented technical features =20
    c. Find faults =20
    d. All the above.
Answer:
****************************************************
12. What strategy did you adopt in choosing your test cases? Please list =
them
    according to the importance of finding defects of your system =
(descending)?
    a. Choose sample of valid inputs =20
    b. Choose those inputs most likely to cause failure =20
    c. Choose inputs according to your experience =20
    d. Other (specify            )
Answer:
****************************************************
13. If you do coverage control, what percent of the code (lines of code) =
do=20
    you think are covered in your test?
    a. <20%  b. 20%-40%  c. 40%-60%  d. 60-80%  e. >80%   f. Not =
Applicable
Answer:
****************************************************
14. In defects you found, what percent of the following problem =
categories=20
should be found in requirements phase? in design phase? in unit test ?
in integration test?
    a. <20%  b. 20%-40%  c. 40%-60%  d. 60-80%  e. >80%   F. Not =
Applicable
Answer:
****************************************************
15. In which areas did you find most of the defects when  you integrate =
and=20
    sell products (someone sell open source products such as RedHat)?
    a. User interface-related problems =20
    b. Database-related problems =20
    c. Network-related problems =20
    d. Logical =20
    e. Other(specify   )
    f. Not Applicable
Answer:
=20
Luyin Zhao
535 N23 Street, #10
Lincoln, NE 68503
(402)438-9511

------=_NextPart_000_0271_01BF2A2B.411F64C0
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Dgb2312 http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Dear =
Mailman,<BR>&nbsp;&nbsp;&nbsp;&nbsp; I'm a=20
graduate student (computer science) in University <BR>of =
Nebraska-Lincoln. The=20
Questionnaire for open source testing <BR>below is for a paper I'm =
working on.=20
Hope you can spend <BR>five minutes to finish it in your busy time. Any =
of your=20
<BR>effort will be greatly =
appreciated!<BR>Luyin<BR>&nbsp;<BR>Questionnaire for=20
Open Source=20
Testing<BR>****************************************************<BR>1. =
What=20
programming language is used in developing your product<BR>&quot;Mailman =

1.1&quot;:?<BR>****************************************************<BR>2.=
 How=20
many developers were involved in your=20
project?<BR>****************************************************<BR>3. =
When do=20
you begin to do testing? <BR>&nbsp;&nbsp;&nbsp; a. Requirement Analysis =
Phase=20
<BR>&nbsp;&nbsp;&nbsp; b. Functional design Phase <BR>&nbsp;&nbsp;&nbsp; =
c.=20
Internal Design Phase <BR>&nbsp;&nbsp;&nbsp; d. Implementation Phase=20
<BR>&nbsp;&nbsp;&nbsp; e. After Implementation <BR>&nbsp;&nbsp;&nbsp; =
Note:=20
Functional design is to describe the features of a system=20
from<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; technique-oriented perspective =
compared=20
with the user-oriented <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; perspective of =

requirement analysis. Internal design is to model=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the implementation of system, such as =
class=20
diagrams.<BR>Answer:<BR>*************************************************=
***<BR>4.=20
The time you spent in testing compared with the total time of=20
development?<BR>&nbsp;&nbsp;&nbsp; a. &lt;20%&nbsp; b. 20%-40%&nbsp; c.=20
40%-60%&nbsp; d. 60-80%&nbsp; e.=20
&gt;80%<BR>Answer:<BR>***************************************************=
*<BR>5.=20
How do you prepare for your testing (using plan or schedule)?=20
<BR>&nbsp;&nbsp;&nbsp; a. Written plan which was modified several =
times&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp; b. One plan draft without further =
modification&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp; c. I prepare it in my brain&nbsp; =
<BR>&nbsp;&nbsp;&nbsp;=20
d. I have no=20
plan<BR>Answer:<BR>****************************************************<B=
R>6. Do=20
you inspect the following items?<BR>&nbsp;&nbsp;&nbsp; a. Requirement=20
Documentation (if you have)&nbsp; <BR>&nbsp;&nbsp;&nbsp; b. Design =
Documentation=20
(if you have)&nbsp; <BR>&nbsp;&nbsp;&nbsp; c. Source code (besides =
relying on=20
compiler and program execution to <BR>find faults in=20
code)<BR>Answer:<BR>****************************************************<=
BR>7.=20
There are some defects resulted from the unclear definition of=20
requirements.<BR>&nbsp;&nbsp; In the total defects of this category you =
found,=20
approximately what <BR>&nbsp;&nbsp; percentage were found in code =
inspections,=20
in unit tests and in system <BR>&nbsp;&nbsp; tests,=20
respectively?<BR>&nbsp;&nbsp; a. &lt;20%&nbsp; b. 20%-40%&nbsp; c. =
40%-60%&nbsp;=20
d. 60-80%&nbsp; e. &gt;80%&nbsp;&nbsp; f. Not=20
applicable<BR>Answer:&nbsp;&nbsp;&nbsp;&nbsp;=20
,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ,&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>****************************************************<BR>8. The =
percent of=20
time you spent in document inspection (compared with total =
<BR>&nbsp;&nbsp;=20
development time) is:<BR>&nbsp;&nbsp;&nbsp; a. &lt;20%&nbsp; b. =
20%-40%&nbsp; c.=20
40%-60%&nbsp; d. 60-80%&nbsp; e. &gt;80%&nbsp;&nbsp; f. Not=20
applicable<BR>Answer:<BR>************************************************=
****<BR>9.=20
How many people did you ask to check your documents or source=20
code?<BR>&nbsp;&nbsp; Do you think it is useful?<BR>&nbsp;&nbsp;&nbsp; =
a.=20
No&nbsp; <BR>&nbsp;&nbsp;&nbsp; b. A little bit&nbsp; =
<BR>&nbsp;&nbsp;&nbsp; c.=20
Useful but not necessary&nbsp; <BR>&nbsp;&nbsp;&nbsp; d. They found lots =
of=20
defects that I haven=92t found&nbsp; <BR>&nbsp;&nbsp;&nbsp; e. =
Absolutely=20
necessary<BR>Answer:<BR>*************************************************=
***<BR>10.=20
Do you use testing tools during your development? The name of=20
it?<BR>Answer:<BR>****************************************************<BR=
>11.=20
What is the basis of your testing?<BR>&nbsp;&nbsp;&nbsp; a. Test whether =
system=20
implemented what user need&nbsp; <BR>&nbsp;&nbsp;&nbsp; b. Test whether =
system=20
implemented technical features&nbsp; <BR>&nbsp;&nbsp;&nbsp; c. Find =
faults&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp; d. All the=20
above.<BR>Answer:<BR>****************************************************=
<BR>12.=20
What strategy did you adopt in choosing your test cases? Please list=20
them<BR>&nbsp;&nbsp;&nbsp; according to the importance of finding =
defects of=20
your system (descending)?<BR>&nbsp;&nbsp;&nbsp; a. Choose sample of =
valid=20
inputs&nbsp; <BR>&nbsp;&nbsp;&nbsp; b. Choose those inputs most likely =
to cause=20
failure&nbsp; <BR>&nbsp;&nbsp;&nbsp; c. Choose inputs according to your=20
experience&nbsp; <BR>&nbsp;&nbsp;&nbsp; d. Other=20
(specify&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
)<BR>Answer:<BR>****************************************************<BR>1=
3. If=20
you do coverage control, what percent of the code (lines of code) do=20
<BR>&nbsp;&nbsp;&nbsp; you think are covered in your =
test?<BR>&nbsp;&nbsp;&nbsp;=20
a. &lt;20%&nbsp; b. 20%-40%&nbsp; c. 40%-60%&nbsp; d. 60-80%&nbsp; e.=20
&gt;80%&nbsp;&nbsp; f. Not=20
Applicable<BR>Answer:<BR>************************************************=
****<BR>14.=20
In defects you found, what percent of the following problem categories=20
<BR>should be found in requirements phase? in design phase? in unit test =
?<BR>in=20
integration test?<BR>&nbsp;&nbsp;&nbsp; a. &lt;20%&nbsp; b. =
20%-40%&nbsp; c.=20
40%-60%&nbsp; d. 60-80%&nbsp; e. &gt;80%&nbsp;&nbsp; F. Not=20
Applicable<BR>Answer:<BR>************************************************=
****<BR>15.=20
In which areas did you find most of the defects when&nbsp; you integrate =
and=20
<BR>&nbsp;&nbsp;&nbsp; sell products (someone sell open source products =
such as=20
RedHat)?<BR>&nbsp;&nbsp;&nbsp; a. User interface-related problems&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp; b. Database-related problems&nbsp; =
<BR>&nbsp;&nbsp;&nbsp;=20
c. Network-related problems&nbsp; <BR>&nbsp;&nbsp;&nbsp; d. =
Logical&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp; e. Other(specify&nbsp;&nbsp; =
)<BR>&nbsp;&nbsp;&nbsp; f.=20
Not Applicable<BR>Answer:<BR>&nbsp;</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Luyin Zhao<BR>535 N23 Street, =
#10<BR>Lincoln, NE=20
68503<BR>(402)438-9511</FONT></DIV></BODY></HTML>

------=_NextPart_000_0271_01BF2A2B.411F64C0--



From richarde@eskom.co.za  Tue Nov  9 07:09:45 1999
From: richarde@eskom.co.za (Richard Ellerbrock)
Date: Tue, 09 Nov 1999 09:09:45 +0200
Subject: [Mailman-Developers] ABEND: problem with sync_members
 command
Message-ID: <s827e4df.049@eskom.co.za>

Ok, I have found the problem. The check routines that validate an e-mail address does not pick up addresses with spaces in them. Thus, the following will cause an ABEND:

richarde. test@eskom.co.za 

Easy to reproduce. It must be in the code that checks e-mail addresses against a regular expression.

Well, I doubt that it will be fixed as I submitted a patch against sync_members to allow getting input from stdio as stated in the help for the command. Nothing as yet.

Is anything happening with mailman development?

--
Richard Ellerbrock
richarde@eskom.co.za

>>> Sean Reifschneider <jafo@tummy.com> 1999/11/08 08:45:18 >>>
On Mon, Nov 08, 1999 at 03:44:59PM +0200, Richard Ellerbrock wrote:
>This is with Mailman 1.1 freshly downloaded. sync_members does not
>complain about any invalid addresses. The number of addresses that I
>want to sync are over 3000! Could this be a problem?

I don't know, but last week I created a new list and freshly inserted over
3000 addresses into it with no problems.

Sean
-- 
 "Engineering Tablets?  Does that mean if I swallow one, I'll be an engineer?"
                 -- Evelyn Mitchell
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
URL: <http://www.tummy.com/xvscan> HP-UX/Linux/FreeBSD/BSDOS scanning software.

_______________________________________________
Mailman-Developers maillist  -  Mailman-Developers@python.org 
http://www.python.org/mailman/listinfo/mailman-developers



From lindsey@ncsa.uiuc.edu  Tue Nov  9 07:40:37 1999
From: lindsey@ncsa.uiuc.edu (Christopher Lindsey)
Date: Tue, 9 Nov 1999 01:40:37 -0600 (CST)
Subject: [Mailman-Developers] ABEND: problem with sync_members
In-Reply-To: <s827e4df.049@eskom.co.za> from "Richard Ellerbrock" at Nov 9, 99 09:09:45 am
Message-ID: <199911090740.BAA32540@ferret.ncsa.uiuc.edu>

> Ok, I have found the problem. The check routines that validate an e-mail address does not pick up addresses with spaces in them. Thus, the following will cause an ABEND:
> 
> richarde. test@eskom.co.za 

For what it's worth, that's not an RFC-compliant address.  Any addresses
with spaces need to be enclosed within quotations, i.e

   "richarde. test"@eskom.co.za 

If I remember, most of the address-related routines in Mailman split
on whitespace when extracting addresses from headers, in the Web interface,
etc., so the issue is unfortunately a lot more complex. 

As far as I know there's currently no way to gracefully handle addresses
with spaces in them.

Another issue I'd like to eventually deal with is plus-addressing, so 
Mailman interprets lindsey@example.com = lindsey+listname@example.com
for purposes of "authentication."

Chris


From richarde@eskom.co.za  Tue Nov  9 08:27:23 1999
From: richarde@eskom.co.za (Richard Ellerbrock)
Date: Tue, 09 Nov 1999 10:27:23 +0200
Subject: [Mailman-Developers] ABEND: problem with sync_members
Message-ID: <s827f713.089@eskom.co.za>

>> Ok, I have found the problem. The check routines that validate an e-mail 
>address does not pick up addresses with spaces in them. Thus, the following 
>will cause an ABEND:
>> 
>> richarde. test@eskom.co.za 
>
>For what it's worth, that's not an RFC-compliant address.  Any addresses
>with spaces need to be enclosed within quotations, i.e
>
>   "richarde. test"@eskom.co.za 

Correct. I have written a routine that grabs addresses from a database. It is rather strange what people enter as e-mail addresses. I then sync this to a mailing list.

What I have done to get around the problem is to modify my SQL statement to exclude addresses with spaces in them. Also works :-)

I had to modify sync_members to accept input from stdio though.


--
Richard Ellerbrock
richarde@eskom.co.za



From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Wed Nov 10 17:31:40 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Wed, 10 Nov 1999 12:31:40 -0500 (EST)
Subject: [Mailman-Developers] Massive changes (Long)
Message-ID: <14377.44028.822009.15906@anthem.cnri.reston.va.us>

Folks, I have some rather massive changes to check into the CVS tree,
which I'm going to explain below.  Grab a cup of coffee and sit back.
:)

I should note that while I've done a lot of testing of this stuff, I'm
sure I've missed things.  I do not recommend using any of this on a
production system, but I would definitely appreciate another set of
eyes and hands taking a look.  I think I have a way to selectively
migrate lists to a new Mailman installation one at a time, so I will
try some of my test lists on python.org.  If all goes well, I may make
y'all guinea pigs in the next round of experiments :)

These changes were precipitated by the observation of occasional poor
performance, and the intermittent reports of duplicate messages.  I
actually gathered enough data on python.org that implicate Mailman's
built-in bulk mailer.  So I wanted to experiment with alternative
delivery strategies.  In the process I got a new Ultra2 for python.org
and decided it was time to play with a different MTA, so I sucked down
Postfix and installed it instead of sendmail.

What I wanted was an architecture that would let us drop in different
delivery schemes easily, so that we could experiment with the best,
and also so sites could easily add whatever delivery machinery made
the most sense for them.  I strongly suspect that no one scheme that
Mailman coudl bundle will be right for everyone.

For a while now, I've hated the tangle of code that gets called when a
message is being delivered.  So I've essentially ripped all that out
for an architecture that I've talked about to a few people already.
The idea is that when a message comes into the system, it is handled
by a "pipeline".  In Python terms, the pipeline is simply a list of
modules, all of which have a function called `process' that takes two
arguments: a MailList instance and a Message instance.  MailLists you
know.  Messages are a subclass of rfc822.Messages with a little bit of
extra stuff for convenience.  Since rfc822.Message now supports a
writeable interface, I was able to get rid of Message.IncomingMessage,
Message.OutgoingMessage, and Message.NewsMessage.

Here's the entire contents of MailList.Post():

    # msg should be an Message.Message object.
    def Post(self, msg):
	self.IsListInitialized()
        # TBD: this is bogus and will later be configurable
        import Mailman.Handlers.HandlerAPI
        Mailman.Handlers.HandlerAPI.process(self, msg)
	self.Save()

You'll see that that is a little bit shorter than what it used to be
:).  `Handlers' is a new package inside Mailman which contains all the
modules for the pipeline.  HandlerAPI.process() basically runs down
the list of pipeline modules, calling each in turn.  The specs for the
<handler>.process() functions say that their return value is ignored,
and they raise an exception if processing of the message is supposed
to stop propagating.

Here's the current list of pipeline modules for normal message
delivery:

    pipeline = ['SpamDetect',
                'Approve',
                'Hold',
                'Cleanse',
                'CookHeaders',
                'ToDigest',
                'ToArchive',
                'ToUsenet',
                'CalcRecips',
                'Decorate',
                'Sendmail',
                'Acknowledge',
                'AfterDelivery',
                ]

The idea here is that each pipeline module does one small thing and
one thing only.  For example, Approve.process() tries to figure out if
the message has been pre-approved.  It will also look for an Approved:
header with a valid password.  All communication between handlers
happens via attributes on the message object, so in the case of the
Approve handler, if it finds a valid "Approve: password" header, it
sets "msg.approved = 1".  Other modules (notably SpamDetect and Hold)
will look for this attribute and short circuit if it finds a true
value.

In a similar vein, ToArchive and ToDigest will look for the `isdigest'
attribute.  If found and true, then the message is a digest so it
won't be sent to the archive, nor will it be appended to the currently
building digest.

Now the neat thing is the Sendmail module.  It's not clever at all, in
fact it just popen's a sendmail (or sendmail-compatible, e.g. postfix)
process, gives the recip addrs on the command line, and pipes the
message to the proc's stdin.  The one complication is that it splits
up the recipients if necessary to keep the command line length
manageable.  What I think is neat is that you could implement an
SMTPDeliver module which uses smtplib.py, or even convert to using
Mailman's current bulk mailer (which I haven't done), or a delivery
scheme of your own choosing.  It should be quite easy to drop in just
drop in this component while keeping everything else the same.  The
Sendmail module rqeuires that the msg object has an attribute called
`recips' which is a list of addresses to send the message to.  The
CalcRecips module sets this attribute.

A couple of things to notice.  First, proper delivery of the message
requires the correct order in the pipeline.  Put Acknowledge before
Sendmail and those who want acks of their messages would get them
before the message was actually sent.  Also, while this seems to work
well for my simple tests, I think I need to play with more aspects
under more realistic load to figure out whether this approach will
work in the long run.  Finally, there's the question of incoming
messages (say injected from Usenet, or via the -request address).  I
think a pipeline will work well here too, e.g. I envision a pipeline
of bounce detectors, but I'm not sure yet how this will integrate with
the outgoing pipeline.

A couple of other random but important notes.  I've also significantly
revamped the whole admin request stuff.  Held messages and
subscriptions are no longer kept in the list object.  This should make
your config.db files considerably smaller and faster to load, and will
hopefully improve overall performance.  All that information is now
kept in a separate database file, which is currently implemented using
Python's anydbm module (this might change).  The good thing is that
this file is only touched when a message or subscription is held, or
when you hit the admindb web page.

I've decided to finally make Python 1.5.2 the minimum supported
platform.  It's been out since April, is very stable, is available for
all platforms (and I think there are RPMs available), and is much much
MUCH better than any previous version of Python.  I'm tired of trying
to keep track of backwards compatibility issues.  So the next version
of Mailman will require at least Python 1.5.2.  I should note that
there will /not/ be a Python 1.5.3 -- Guido's decided that the next
release will be 1.6, but that will definitely not be out (other than
via the anonCVS tree) until next year some time.

So... I'm going to check all these changes in so that I can continue
testing.  I'll hopefully also be ripping out lots more unused code.
I'm not sure how much more time I'm going to be hacking on it, but I
need to get this stuff working for python.org so at least until then.

Apologies in advance to the I18N'ers for not getting to that stuff,
and for making so many changes under the hood.  If this stuff turns
out to work well, I'll try to spend some time getting those mods
integrated.

Thanks,
-Barry


From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Wed Nov 10 20:29:44 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Wed, 10 Nov 1999 15:29:44 -0500 (EST)
Subject: [Mailman-Developers] Massive changes (Long)
References: <14377.44028.822009.15906@anthem.cnri.reston.va.us>
Message-ID: <14377.54712.308533.182882@anthem.cnri.reston.va.us>

Just to let y'all know, I've finished this round of check-ins.  I will
be testing stuff out with the current snapshot and making any fixes
that are necessary.  If you find problems, please let me know.

-Barry


From bwarsaw@python.org  Fri Nov 12 20:00:30 1999
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Fri, 12 Nov 1999 15:00:30 -0500 (EST)
Subject: [Mailman-Developers] Changes working, and list moved
Message-ID: <14380.29150.737226.76974@anthem.cnri.reston.va.us>

Hey folks, the purpose of this message is twofold.  First, it's to let
you know that I feel pretty confident about the new changes, at least
insofar as they system seems to be working pretty well.  I don't yet
know what impact, if any there will be on performance.

Second, I've moved this mailing list to our new server so at least it
should /seem/ faster (the new one is an Ultra2, the old one is a
Sparc5).  I'll be keeping an eye on this list over the next couple of
days to make sure the new version is working properly.  If so, then
I'll probably start moving all the existing python.org mailing lists
over to it (once I've verified our sysadmins are actually backing up
the Ultra2).

So you guys are the guinea pigs for the new changes.  You should not
notice any differences; the email addresses are unchanged, as are the
URLs.  You'll notice the new hostname leak in a couple of places
(e.g. as URLs for the Mailman logo and the public archives), but those
aren't important enough to fix at the moment.

If you notice /anything/ strange going on, first try to email this
list.  If you suspect that the messages aren't getting through, email
me directly at bwarsaw@python.org.

Okay, have fun!
-Barry


From bwarsaw@python.org  Fri Nov 12 20:08:39 1999
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Fri, 12 Nov 1999 15:08:39 -0500 (EST)
Subject: [Mailman-Developers] Changes working, and list moved
Message-ID: <14380.29639.55451.890041@anthem.cnri.reston.va.us>

Hey folks, the purpose of this message is twofold.  First, it's to let
you know that I feel pretty confident about the new changes, at least
insofar as they system seems to be working pretty well.  I don't yet
know what impact, if any there will be on performance.

Second, I've moved this mailing list to our new server so at least it
should /seem/ faster (the new one is an Ultra2, the old one is a
Sparc5).  I'll be keeping an eye on this list over the next couple of
days to make sure the new version is working properly.  If so, then
I'll probably start moving all the existing python.org mailing lists
over to it (once I've verified our sysadmins are actually backing up
the Ultra2).

So you guys are the guinea pigs for the new changes.  You should not
notice any differences; the email addresses are unchanged, as are the
URLs.  You'll notice the new hostname leak in a couple of places
(e.g. as URLs for the Mailman logo and the public archives), but those
aren't important enough to fix at the moment.

If you notice /anything/ strange going on, first try to email this
list.  If you suspect that the messages aren't getting through, email
me directly at bwarsaw@python.org.

Okay, have fun!
-Barry


From bwarsaw@python.org  Fri Nov 12 20:09:36 1999
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Fri, 12 Nov 1999 15:09:36 -0500 (EST)
Subject: [Mailman-Developers] Changes working, and list moved
Message-ID: <14380.29696.616826.310655@anthem.cnri.reston.va.us>

Hey folks, the purpose of this message is twofold.  First, it's to let
you know that I feel pretty confident about the new changes, at least
insofar as they system seems to be working pretty well.  I don't yet
know what impact, if any there will be on performance.

Second, I've moved this mailing list to our new server so at least it
should /seem/ faster (the new one is an Ultra2, the old one is a
Sparc5).  I'll be keeping an eye on this list over the next couple of
days to make sure the new version is working properly.  If so, then
I'll probably start moving all the existing python.org mailing lists
over to it (once I've verified our sysadmins are actually backing up
the Ultra2).

So you guys are the guinea pigs for the new changes.  You should not
notice any differences; the email addresses are unchanged, as are the
URLs.  You'll notice the new hostname leak in a couple of places
(e.g. as URLs for the Mailman logo and the public archives), but those
aren't important enough to fix at the moment.

If you notice /anything/ strange going on, first try to email this
list.  If you suspect that the messages aren't getting through, email
me directly at bwarsaw@python.org.

Okay, have fun!
-Barry


From bwarsaw@python.org  Fri Nov 12 20:13:41 1999
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Fri, 12 Nov 1999 15:13:41 -0500 (EST)
Subject: [Mailman-Developers] Changes working, and list moved
Message-ID: <14380.29941.960244.326705@anthem.cnri.reston.va.us>

Hey folks, the purpose of this message is twofold.  First, it's to let
you know that I feel pretty confident about the new changes, at least
insofar as they system seems to be working pretty well.  I don't yet
know what impact, if any there will be on performance.

Second, I've moved this mailing list to our new server so at least it
should /seem/ faster (the new one is an Ultra2, the old one is a
Sparc5).  I'll be keeping an eye on this list over the next couple of
days to make sure the new version is working properly.  If so, then
I'll probably start moving all the existing python.org mailing lists
over to it (once I've verified our sysadmins are actually backing up
the Ultra2).

So you guys are the guinea pigs for the new changes.  You should not
notice any differences; the email addresses are unchanged, as are the
URLs.  You'll notice the new hostname leak in a couple of places
(e.g. as URLs for the Mailman logo and the public archives), but those
aren't important enough to fix at the moment.

If you notice /anything/ strange going on, first try to email this
list.  If you suspect that the messages aren't getting through, email
me directly at bwarsaw@python.org.

Okay, have fun!
-Barry


From bwarsaw@python.org  Fri Nov 12 20:16:07 1999
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Fri, 12 Nov 1999 15:16:07 -0500 (EST)
Subject: [Mailman-Developers] Changes working, and list moved
Message-ID: <14380.30087.203052.100118@anthem.cnri.reston.va.us>

Hey folks, the purpose of this message is twofold.  First, it's to let
you know that I feel pretty confident about the new changes, at least
insofar as they system seems to be working pretty well.  I don't yet
know what impact, if any there will be on performance.

Second, I've moved this mailing list to our new server so at least it
should /seem/ faster (the new one is an Ultra2, the old one is a
Sparc5).  I'll be keeping an eye on this list over the next couple of
days to make sure the new version is working properly.  If so, then
I'll probably start moving all the existing python.org mailing lists
over to it (once I've verified our sysadmins are actually backing up
the Ultra2).

So you guys are the guinea pigs for the new changes.  You should not
notice any differences; the email addresses are unchanged, as are the
URLs.  You'll notice the new hostname leak in a couple of places
(e.g. as URLs for the Mailman logo and the public archives), but those
aren't important enough to fix at the moment.

If you notice /anything/ strange going on, first try to email this
list.  If you suspect that the messages aren't getting through, email
me directly at bwarsaw@python.org.

Okay, have fun!
-Barry


From bwarsaw@python.org  Fri Nov 12 20:39:04 1999
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Fri, 12 Nov 1999 15:39:04 -0500 (EST)
Subject: [Mailman-Developers] Changes working, and list moved
Message-ID: <14380.31464.240034.731424@anthem.cnri.reston.va.us>

Hey folks, the purpose of this message is twofold.  First, it's to let
you know that I feel pretty confident about the new changes, at least
insofar as they system seems to be working pretty well.  I don't yet
know what impact, if any there will be on performance.

Second, I've moved this mailing list to our new server so at least it
should /seem/ faster (the new one is an Ultra2, the old one is a
Sparc5).  I'll be keeping an eye on this list over the next couple of
days to make sure the new version is working properly.  If so, then
I'll probably start moving all the existing python.org mailing lists
over to it (once I've verified our sysadmins are actually backing up
the Ultra2).

So you guys are the guinea pigs for the new changes.  You should not
notice any differences; the email addresses are unchanged, as are the
URLs.  You'll notice the new hostname leak in a couple of places
(e.g. as URLs for the Mailman logo and the public archives), but those
aren't important enough to fix at the moment.

If you notice /anything/ strange going on, first try to email this
list.  If you suspect that the messages aren't getting through, email
me directly at bwarsaw@python.org.

Okay, have fun!
-Barry


From bwarsaw@python.org  Fri Nov 12 20:42:26 1999
From: bwarsaw@python.org (bwarsaw@python.org)
Date: Fri, 12 Nov 1999 15:42:26 -0500 (EST)
Subject: [Mailman-Developers] Changes working, and list moved
Message-ID: <14380.31666.51895.556833@anthem.cnri.reston.va.us>

Hey folks, the purpose of this message is twofold.  First, it's to let
you know that I feel pretty confident about the new changes, at least
insofar as they system seems to be working pretty well.  I don't yet
know what impact, if any there will be on performance.

Second, I've moved this mailing list to our new server so at least it
should /seem/ faster (the new one is an Ultra2, the old one is a
Sparc5).  I'll be keeping an eye on this list over the next couple of
days to make sure the new version is working properly.  If so, then
I'll probably start moving all the existing python.org mailing lists
over to it (once I've verified our sysadmins are actually backing up
the Ultra2).

So you guys are the guinea pigs for the new changes.  You should not
notice any differences; the email addresses are unchanged, as are the
URLs.  You'll notice the new hostname leak in a couple of places
(e.g. as URLs for the Mailman logo and the public archives), but those
aren't important enough to fix at the moment.

If you notice /anything/ strange going on, first try to email this
list.  If you suspect that the messages aren't getting through, email
me directly at bwarsaw@python.org.

Okay, have fun!
-Barry


From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Fri Nov 12 20:46:01 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Fri, 12 Nov 1999 15:46:01 -0500 (EST)
Subject: [Mailman-Developers] Changes working, and list moved
References: <14380.31666.51895.556833@anthem.cnri.reston.va.us>
Message-ID: <14380.31881.124703.786223@anthem.cnri.reston.va.us>

This is another test.  Please ignore.
-Barry


From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Fri Nov 12 20:48:17 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Fri, 12 Nov 1999 15:48:17 -0500 (EST)
Subject: [Mailman-Developers] Changes working, and list moved
References: <14380.31666.51895.556833@anthem.cnri.reston.va.us>
 <14380.31881.124703.786223@anthem.cnri.reston.va.us>
Message-ID: <14380.32017.428596.333228@anthem.cnri.reston.va.us>

Okay, I think I've now got Mailman 1.1+ and Postfix working nicely
together.  You might see a couple of extra messages in the archives
though :)

-Barry


From bwarsaw@server.python.net  Sat Nov 13 00:20:33 1999
From: bwarsaw@server.python.net (bwarsaw@server.python.net)
Date: 13 Nov 1999 00:20:33 -0000
Subject: [Mailman-Developers] test from off-site
Message-ID: <19991113002033.32632.qmail@server.python.net>

I'm sending this from the starship.  Please ignore.
-Barry


From bwarsaw@server.python.net  Sat Nov 13 00:33:16 1999
From: bwarsaw@server.python.net (bwarsaw@server.python.net)
Date: 13 Nov 1999 00:33:16 -0000
Subject: [Mailman-Developers] test #2
Message-ID: <19991113003316.39.qmail@server.python.net>

plz ignore


From pioppo@ferrara.linux.it  Sun Nov 14 13:53:39 1999
From: pioppo@ferrara.linux.it (Pioppo)
Date: Sun, 14 Nov 1999 14:53:39 +0100
Subject: [Mailman-Developers] Giving Translation Help
Message-ID: <99111414561702.00618@abulafia.4net.it>

Hi from Italy

What is the best procedure to make a full italian translation for mailman
and to have it distributed within the next (I hope) release of mailman?

Thanks

-- 
    Simone Piunno,  http://pioppo.cjb.net,  simone@piunno.com
     Ferrara Linux Users Group  -->  http://ferrara.linux.it
      ICQ UIN: 6914669 pioppo@IRCnet on #ferrara, #linux-it 
GnuPG/PGP5 fp: 9C15 F0D3 E309 3593 AC95  2C92 A0CD 52B4 8603 14FC


From jcrey@uma.es  Mon Nov 15 08:19:28 1999
From: jcrey@uma.es (Juan Carlos Rey Anaya)
Date: Mon, 15 Nov 1999 09:19:28 +0100
Subject: [Mailman-Developers] Giving Translation Help
References: <99111414561702.00618@abulafia.4net.it>
Message-ID: <382FC210.D7D65A7E@uma.es>

Pioppo wrote:
> 
> What is the best procedure to make a full italian translation for mailman
> and to have it distributed within the next (I hope) release of mailman?
> 

The process of Mailman i18n is in progress and is not a public subject
(yet).
Please contact Victoriano.giralt@uma.es or with me for a detailed to-do
list.

Actually Mailman is translated to:
English :-)
Spanish and
German

You can see a FULLY operational version at (of course demo version until
it will be included in a final release):
http://joker.sci.uma.es/mailman/listinfo/test

Cheers
-- 
                          ___
                         / F \
                        [[[]]]]
                        ( O O )
   #----------------0000--(_)--0000---------------#
   |    Juan Carlos Rey Anaya (jcrey@uma.es)      |
   |      Servicio Central de informática         |
   |       Universidad de Málaga - España         |
   #----------------------------------------------#
   #      Solo se que cada vez se menos :-|       #
   #----------------------------------------------#


From Rick.Niess@usm.edu  Mon Nov 15 23:28:55 1999
From: Rick.Niess@usm.edu (Rick Niess)
Date: Mon, 15 Nov 1999 17:28:55 -0600 (CST)
Subject: [Mailman-Developers] Features requested...
Message-ID: <Pine.LNX.4.10.9911151607270.30676-100000@netserver3.otr.usm.edu>

Hi Everyone,

     I have a several ideas for features that may be of interest.  Their
implementation would certainly be to my benefit.  I've listed them below.

     FYI, I'm testing out Mailman as a replacement for my campus' existing
Majordomo setup.  If I can just get a few issued resolved, I think the
transition will go easily.

1) Please add an option so subscribers can elect to show only the username
part of their e-mail address in the subscriber list instead of the whole
thing (regardless of the @->" at " conversion).

2) In the section of the listinfo page where a user can subscribe to the
list in question, please add another radio-button option for "Conceal
yourself from subscriber list?" if the list's subscriber list can be seen
by the list members or the public.  I'm somewhat of an anti-spam nut so I
don't like having my e-mail address publically visible in any form.

3) Allow the system-wide admin to disable the mail->news and news->mail
gatewaying for the whole system and/or for selected lists. (I've got some
list admins that want to use this, but I *really* don't want to see that
kind of traffic on my server.  Not to mention the liability issues...)

4) On the membership management admin page, please setup a mechanism for
large lists to limit the display of user options to X number of users per
page.  It's a killer to try to admin large lists from slow machines with
limited memory. (ex, took me a long time and a lot of swapping to load the
page for a 3000 member list)

5) Please setup a means by which a user can specify what additional
addresses he/she posts from other than their subscription address. (For
example, my campus has a mail aliasing system so that all public addresses
have the form "firstname.lastname@usm.edu" or similar.  But the address
they post from may be "username@host.usm.edu" or similar.  This becomes a
problem for lists that have member_posting_only turned on.)

6) Please setup a mechanism for a pre-made set of options to be used
as defaults when creating new lists.  For instance, on our campus, we have
a form that prospective list owners fill out to request a new list.  On
this form, we have the following options for them to "check" that
determine how their list is initially setup.:

Archived list (Duh)
Closed list (Subscriptions requests must be approved list list owner.
             Otherwise list is "Open" and anyone may subscribe.)
Secured list (Only list members may post to the list)
Moderated list (list owner must approve all posts to the list)
Announcement (List will be used for outgoing announcements only.  Implies
              moderated and secured.)

I don't mind creating files with all of the configuration options and
their default config values.  I just need a snippet of code to read the
values in and use those as defaults when creating the list.  And then,
perhaps if I combined that with #7 below, I could get it to automatically
import the configuration of a previous majordomo list... (I don't know how
either of these would work with the idea to create lists from a site admin
page, tho.  Perhaps the site admin could choose from a pull-down menu of
option pre-sets or pre-existing majordomo lists when creating a mailman
list?)

7) If anyone has written a withlist module that can read in the values in
an existing Majordomo 1.94 config file and update the corrosponding values
in a Mailman list's config db, I'd be ever so greatful to get a copy. This
would make transitioning to mailman *so* much easier than having to do
each list by hand through the web interface.

8) The <body> tag is not currently setup right for error pages.

9) Please build-in the option for individual list owners to filter binary
attachments. (I think something like this is already in the works, but I'd
like it to be a per-list option settable by the list owner.)

10) In the pipermail archives, please do the following:

  - move the archives to http://host/mailman/archives/listname or provide
    a redirect from there to http://host/pipermail/listname.
  - implelement a link for users to reply to posts in an archive by using
    a mailto: URL to open up a mailer window from their browser.  Or
    perhaps make this optional on a per-list basis.
    (Note: this might break threading if a specific "In-Reply-to" header
     can't be added)
  - in threaded view:
     (a) add links at the bottom of each post to go back to the previous
         thread and forward to the next.
     (b) perhaps setup a mode where a user could see all the threads
         expanded on one page (as it is now) or see all the thread titles
         on one page and clicking them expands the thread into a new page.


     Lastly, I'd like to note that, while I understand most of what's
going on in the code, I don't have time ATM to sit down and really learn
Python.  Hence, I don't have the expertise to go about making most of
these modifications myself.  I do, however, plan to sit down and learn
Python as well as possible over the holiday break.  So perhaps I can pitch
in directly during the new year.

     Thank-you for your attention.  I look forward to hearing from anyone
who can help! ;-)

						~ Rick Niess ~
--
.oooO "Man with closed Oooo.    Rick C. Niess
(   )   mouth gathers  (   )    University of Southern Miss.
 \ (      no foot!"     ) /     guardian@bark.cc.usm.edu
--\_)------------------(_/-------------------------------







From jafo@tummy.com  Tue Nov 16 02:53:34 1999
From: jafo@tummy.com (Sean Reifschneider)
Date: Mon, 15 Nov 1999 19:53:34 -0700
Subject: [Mailman-Developers] Features requested...
In-Reply-To: <Pine.LNX.4.10.9911151607270.30676-100000@netserver3.otr.usm.edu>; from Rick Niess on Mon, Nov 15, 1999 at 05:28:55PM -0600
References: <Pine.LNX.4.10.9911151607270.30676-100000@netserver3.otr.usm.edu>
Message-ID: <19991115195334.C26336@tummy.com>

On Mon, Nov 15, 1999 at 05:28:55PM -0600, Rick Niess wrote:
>4) On the membership management admin page, please setup a mechanism for
>large lists to limit the display of user options to X number of users per
>page.  It's a killer to try to admin large lists from slow machines with

Hmm, it already does that.  When you select membership, it displays them
in chunks of 10 or something.  I've upped mine to 30, and would actually
prefer 100.

I do note that with my 1.0 install, if I log in with the site-admin
password, I can't select the broken-out lists (it asks for the password
again, then takes me back to the first chunk, even though it says
"chunk=3" or whatever in the URL.

>5) Please setup a means by which a user can specify what additional
>addresses he/she posts from other than their subscription address. (For
>example, my campus has a mail aliasing system so that all public addresses

The current way we're doing this is that if users have multiple addresses
they want to post from, they have to subscribe once for each of those
addresses, and then only enable delivery on ONE of them.

For you, it sounds like you may want to limit it to members only, but then
allow posting from anyone who's e-mail address is "*@usm.edu" or
"*@*.usm.edu"...  Not ideal, but it sounds like your environment doesn't
really keep users from having a new address every week, and that's hard
to predict.

>  - move the archives to http://host/mailman/archives/listname or provide
>    a redirect from there to http://host/pipermail/listname.

Correct me if I'm wrong, but can't you do that in Apache with a slightly
modified version of the lines you already have in there to get the
"/mailman/" and "/pipermail/" URLs to work?

>     Lastly, I'd like to note that, while I understand most of what's
>going on in the code, I don't have time ATM to sit down and really learn
                         ^^^^^^^^^^^^^^^^^^^

Yeah, that seems to be the common problem these days.  Too much demand,
too few geeks.

Sean
-- 
 "Where are we going?"  "Planet Ten!"  "When?"  "Real soon!"
                 -- _Buckaroo_Banzai_
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
URL: <http://www.tummy.com/xvscan> HP-UX/Linux/FreeBSD/BSDOS scanning software.


From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Tue Nov 16 03:39:01 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Mon, 15 Nov 1999 22:39:01 -0500 (EST)
Subject: [Mailman-Developers] Features requested...
References: <Pine.LNX.4.10.9911151607270.30676-100000@netserver3.otr.usm.edu>
Message-ID: <14384.53717.606487.837270@anthem.cnri.reston.va.us>

Sean responded to a bunch of Rick's points, and I'll just add a few
more thoughts.

>>>>> "RN" == Rick Niess <rniess@netserver3.otr.usm.edu> writes:

    RN> 1) Please add an option so subscribers can elect to show only
    RN> the username part of their e-mail address in the subscriber
    RN> list instead of the whole thing (regardless of the @->" at "
    RN> conversion).

The problem here is that we don't actually keep that information
around in the database.  This is bogus, and is something that I hope
will get fixed when we have a real User database (don't ask when ;)

    RN> 2) In the section of the listinfo page where a user can
    RN> subscribe to the list in question, please add another
    RN> radio-button option for "Conceal yourself from subscriber
    RN> list?"

I'd actually like to see more options at the subscription page, if not
all the options a user can change later (that might be too cluttered
and daunting though).

    RN> 3) Allow the system-wide admin to disable the mail->news and
    RN> news->mail gatewaying for the whole system and/or for selected
    RN> lists.

You can disable news->mail easily by shutting off the cron entry for
gate_news.  Shutting off mail->news will actually be much easier to
accomplish with the current CVS snapshot, since you can just edit out
the ToUsenet module from the message delivery pipeline.

There's a meta-issue about providing more site configuration options
via the Web, and that's definitely something I'd like to improve in
the future.

    RN> 5) Please setup a means by which a user can specify what
    RN> additional addresses he/she posts from other than their
    RN> subscription address. (For example, my campus has a mail
    RN> aliasing system so that all public addresses have the form
    RN> "firstname.lastname@usm.edu" or similar.  But the address they
    RN> post from may be "username@host.usm.edu" or similar.  This
    RN> becomes a problem for lists that have member_posting_only
    RN> turned on.)

Again, with a real User database, we could easily allow users to
subscribe multiple addresses, enabling delivery to some or all of
those addresses, and allowing postings from any of a User's known
addresses.  Very difficult to do right now unfortunately.

    RN> 6) Please setup a mechanism for a pre-made set of options to
    RN> be used as defaults when creating new lists.

I've thought about this, but haven't had time to work on it.  It
actually would be easy to do (contributions?? :).  Remember that
bin/newlist isn't magic -- it's really quite simple.  What you could
do is hack this script to include various common list "personalities",
which really just means certain list option settings, and then just
make those settings after the call to newlist.Create().

A simple hack would be to just have a bunch of classes in the newlist
script which implement these defaults, and add a command line switch
to invoke one of those classes on the newly created list.  If you want
to get fancy, you could publish an API and let folks add their own
list personalities.  newlist would try to import a module, dig a class
out, call the API method on the list object, and then Save it.
    
    RN> 7) If anyone has written a withlist module that can read in
    RN> the values in an existing Majordomo 1.94 config file and
    RN> update the corrosponding values in a Mailman list's config db,
    RN> I'd be ever so greatful to get a copy.

And if you do, please let me know, 'cause I'd love to add something
like this to the distribution!

    RN> 8) The <body> tag is not currently setup right for error
    RN> pages.

I don't understand; I guess you mean the driver script is broken?  Can
you give me more details?

    RN> 9) Please build-in the option for individual list owners to
    RN> filter binary attachments. (I think something like this is
    RN> already in the works, but I'd like it to be a per-list option
    RN> settable by the list owner.)

Again, while this functionality doesn't exist yet, the new message
delivery architecture could accomodate this much more easily.

    RN> 10) In the pipermail archives, please do the following:

I'd love it if someone became the Pipermail champion.  I just don't
have the wherewithal to do much development on this code.

    RN>      Lastly, I'd like to note that, while I understand most of
    RN> what's going on in the code, I don't have time ATM to sit down
    RN> and really learn Python.  Hence, I don't have the expertise to
    RN> go about making most of these modifications myself.  I do,
    RN> however, plan to sit down and learn Python as well as possible
    RN> over the holiday break.  So perhaps I can pitch in directly
    RN> during the new year.

Well Rick, it'll probably take you about a day to learn all the Python
you need to become a prolific Mailman hacker!  Just be sure to try it
/before/ you eat the turkey dinner and get all "stuffed". :)

-Barry


From cherub@azrael.dyn.cheapnet.net  Tue Nov 16 04:24:09 1999
From: cherub@azrael.dyn.cheapnet.net (Steven Hazel)
Date: Mon, 15 Nov 1999 22:24:09 -0600 (CST)
Subject: [Mailman-Developers] Features requested...
In-Reply-To: <14384.53717.606487.837270@anthem.cnri.reston.va.us>
 (bwarsaw@cnri.reston.va.us)
References: <Pine.LNX.4.10.9911151607270.30676-100000@netserver3.otr.usm.edu> <14384.53717.606487.837270@anthem.cnri.reston.va.us>
Message-ID: <m11naA5-0007SjC@azrael.dyn.cheapnet.net>

   The problem here is that we don't actually keep that information
   around in the database.  This is bogus, and is something that I hope
   will get fixed when we have a real User database (don't ask when ;)

What are the current plans for this?  I'd like to help.  I should have
some time over the coming holidays.

-S


From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Tue Nov 16 04:22:08 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Mon, 15 Nov 1999 23:22:08 -0500 (EST)
Subject: [Mailman-Developers] Digest #399
Message-ID: <14384.56304.891547.558006@anthem.cnri.reston.va.us>

Sorry folks, there was a bug in the new CalcRecips module that broke
the last digest delivery.  I think I've fixed it now but here's what
happened:

If you are a non-digest member, you erroneously got digest #399.
Sorry about that!

If you are a digest member you did not get digest #399.  Please check
the archives for the articles you missed.  Here's the list of
subjects:

  1. Changes working, and list moved (mailman-developers-admin@python.org)
  2. Changes working, and list moved (mailman-developers-admin@python.org)
  3. Changes working, and list moved (mailman-developers-admin@python.org)
  4. Changes working, and list moved (mailman-developers-admin@python.org)
  5. Changes working, and list moved (mailman-developers-admin@python.org)
  6. Changes working, and list moved (mailman-developers-admin@python.org)
  7. Changes working, and list moved (mailman-developers-admin@python.org)
  8. Re: Changes working, and list moved (Barry A. Warsaw)
  9. Re: Changes working, and list moved (Barry A. Warsaw)
  10. test from off-site (mailman-developers-admin@python.org)
  11. test #2 (mailman-developers-admin@python.org)
  12. Giving Translation Help (Pioppo)
  13. Re: Giving Translation Help (Juan Carlos Rey Anaya)
  14. Features requested... (Rick Niess)
  15. Re: Features requested... (Sean Reifschneider)
  16. Re: Features requested... (Barry A. Warsaw)

Ain't it fun being a guinea pig? :)

Sorry for any inconvenience...
-Barry


From bwarsaw@python.org  Tue Nov 16 04:56:56 1999
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Mon, 15 Nov 1999 23:56:56 -0500 (EST)
Subject: [Mailman-Developers] Features requested...
References: <Pine.LNX.4.10.9911151607270.30676-100000@netserver3.otr.usm.edu>
 <14384.53717.606487.837270@anthem.cnri.reston.va.us>
 <m11naA5-0007SjC@azrael.dyn.cheapnet.net>
Message-ID: <14384.58392.966859.375322@anthem.cnri.reston.va.us>

>>>>> "SH" == Steven Hazel <cherub@azrael.dyn.cheapnet.net> writes:

    Me>    The problem here is that we don't actually keep that
    Me> information around in the database.  This is bogus, and is
    Me> something that I hope will get fixed when we have a real User
    Me> database (don't ask when ;)

    SH> What are the current plans for this?  I'd like to help.  I
    SH> should have some time over the coming holidays.

Well, there are a number of questions (if it was an easy hack it'd
already be done :).

First, do we want to use a real OODB underneath (such as ZODB), or do
we cook our own?  If we cook our own, do we modify Mailman to run as a
long-running process to make things efficient?  How do we handle
safely modifying the user database (e.g. a user adding email addresses
to their profiles)?  There are also UI issues for making all this
convenient for users.  Finally, a user database should be robust
enough to handle specifying various other roles.  IOW, users can also
be list admins, list moderators, and site admins.

Too sleepy to write more tonight.

-Barry


From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Thu Nov 18 01:37:58 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Wed, 17 Nov 1999 20:37:58 -0500 (EST)
Subject: [Mailman-Developers] Re: [Mailman-Users] optimizing mail delivery
References: <3832B316.43C5FDAC@bcb.gov.br>
 <klaubert@bcb.gov.br>
 <E11oAim-0002Q9-00@under.eng.cp.net>
 <19991117144753.A17570@xcski.com>
Message-ID: <14387.22646.76313.150613@anthem.cnri.reston.va.us>

>>>>> "PT" == Paul Tomblin <ptomblin@xcski.com> writes:

    PT> Wrong.  Sendmail *does* do this for you.  If you have a bunch
    PT> of people on a list in random order, sendmail will work
    PT> through the list in order, but every time it connects to a
    PT> domain, it will send one message to *all* the members of the
    PT> list at that domain.  One of my most popular lists has at
    PT> least 30% of its subscribers at panix.com, and another 10% at
    PT> best.com.  When it was on majordomo, the entire list was
    PT> passed off to sendmail in one chunk.  Since one of the
    PT> panix.com people is first on the list, all the panixians got
    PT> their mail first, then a few more people, then all the people
    PT> at best.com, etc.  Now that I'm using mailman, and it's split
    PT> into 5 chunks, I've noticed that one of the chunks is all
    PT> panixians, which goes in one message to panix, and one of the
    PT> chunks is almost all bestians, which also goes in one message.

So do you think the Mailman way is better or worse?  I'm curious
because I'm trying to decide whether I should port Mailman 1.0's bulk
mailer code to the new message pipeline.

In the current 1.2 code base (available via the anonCVS), I os.popen()
sendmail[1] passing the entire recipient list on the command line,
then I pipe the message text to stdin and let the MTA do the rest.
There's one complication; if the length of the recipients list is
greater than a certain length (current 3000), I chop it up into
multiple popens, but I don't do any sorting of the recipient list.

The advantage I see of this is that sendmail can do it's thing
asychronously, without keeping the list object locked the entire
time.  The disadvantage is that Mailman is only aware of delivery
problems if the delivery bounces.

I could see trying to sort the recips on the domain name if the total
length is > 3000.  I can also see porting the local-smptd delivery
scheme of the current bulk mailer, but fixing some of the problems in
the 1.0 code base (and there are quite a few).  I'm leary though of
stepping on too much of the MTA's toes -- a good MTA should just do
the right thing.

Another alternative, which would be less work and delegates all
delivery to the MTA, is to just pump all the recips to the local smtpd
via smtplib.py.  The advantage here is that again we're MTA
independent, but the disadvantage is that Mailman's delivery is
synchronous with the smtpd.  We'd have to be very sure to unlock the
list object during this transaction (but watching out for race
conditions, locking again if failure status's are handled directly,
etc.)  More code, more opportunity for bugs.

Comments?

-Barry

[1] I actually don't use sendmail, I use postfix, but the code is
easily configured to use anything with a sendmail compatible command
line interface.


From ptomblin@xcski.com  Thu Nov 18 01:45:13 1999
From: ptomblin@xcski.com (Paul Tomblin)
Date: Wed, 17 Nov 1999 20:45:13 -0500
Subject: [Mailman-Developers] Re: [Mailman-Users] optimizing mail delivery
In-Reply-To: <14387.22646.76313.150613@anthem.cnri.reston.va.us>; from Barry A. Warsaw on Wed, Nov 17, 1999 at 08:37:58PM -0500
References: <3832B316.43C5FDAC@bcb.gov.br> <klaubert@bcb.gov.br> <E11oAim-0002Q9-00@under.eng.cp.net> <19991117144753.A17570@xcski.com> <14387.22646.76313.150613@anthem.cnri.reston.va.us>
Message-ID: <19991117204513.A1135@xcski.com>

Quoting Barry A. Warsaw (bwarsaw@cnri.reston.va.us):
> So do you think the Mailman way is better or worse?  I'm curious
> because I'm trying to decide whether I should port Mailman 1.0's bulk
> mailer code to the new message pipeline.

Personally, I think you should leave it to the MTA to make the decisions on
how to deliver the mail more efficiently.  Anybody who wants more parallelism
can find an MTA to do that.  And that leaves Mailman to concentrate on doing
the things it does well, rather than second guessing the MTA.

-- 
Paul Tomblin, not speaking for anybody.
SETI@Home:  Finally a *good* way to impress Jodie Foster
http://www.setiathome.ssl.berkeley.edu/


From claw@cp.net  Thu Nov 18 02:04:21 1999
From: claw@cp.net (J C Lawrence)
Date: Wed, 17 Nov 1999 18:04:21 -0800
Subject: [Mailman-Developers] Re: [Mailman-Users] optimizing mail delivery
In-Reply-To: Message from "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
 of "Wed, 17 Nov 1999 20:37:58 EST." <14387.22646.76313.150613@anthem.cnri.reston.va.us>
References: <3832B316.43C5FDAC@bcb.gov.br> <klaubert@bcb.gov.br> <E11oAim-0002Q9-00@under.eng.cp.net> <19991117144753.A17570@xcski.com>  <14387.22646.76313.150613@anthem.cnri.reston.va.us>
Message-ID: <E11oGvt-0004Z6-00@under.eng.cp.net>

On Wed, 17 Nov 1999 20:37:58 -0500 (EST) 
Barry A Warsaw <bwarsaw@cnri.reston.va.us> wrote:

> So do you think the Mailman way is better or worse?  I'm curious
> because I'm trying to decide whether I should port Mailman 1.0's
> bulk mailer code to the new message pipeline.

MailMan's current code is definitely in the "good enough"
category.  

> In the current 1.2 code base (available via the anonCVS), I
> os.popen() sendmail[1] passing the entire recipient list on the
> command line, then I pipe the message text to stdin and let the
> MTA do the rest.  There's one complication; if the length of the
> recipients list is greater than a certain length (current 3000), I
> chop it up into multiple popens, but I don't do any sorting of the
> recipient list.

My view is that appropriate and efficient handling of mail for
delivery is the domain of the MTA, and should not be the domain of
MUA's (in which camp MailMan sorta falls).  As such domain sorting
is pleasant, it really only acts to further bolster technically
lagging mail servers which are in need of new life anyways.

> The advantage I see of this is that sendmail can do it's thing
> asychronously, without keeping the list object locked the entire
> time.  The disadvantage is that Mailman is only aware of delivery
> problems if the delivery bounces.

Which of course requires a local MTA, which the current design
doesn't.

What actually needs to happen (presuming my current understanding of
the source is correct) is that the abstraction of MailMan's internal
mail queue needs to be finished.  Then, a mail broadcast attempt
would only stuff messages (cheaply) into the MailMan queue
mechanism, and then return, unlocking the list objects.  The queue
object of course can be lock free (lockless DB's aren't difficult)
and you then merely need to run a could of MailMan queue runners to
pipe it to the MTA.

One the messages are stuffed, you can then fork a queue runner,
which, if there are already sufficient queue runners immediately
dies.  If more queue runners are needed however, it proceeds to grab 
messages and stuff them at the MTA in the normal fashion over SMTP.

Note:  If you do this adding VERP support becomes a doddle.

> I'm leary though of stepping on too much of the MTA's toes -- a
> good MTA should just do the right thing.

This is perhaps the best point.  Spending time to further bolster
fading technologies when better services are freely available hardly 
seems worth it.  

> Another alternative, which would be less work and delegates all
> delivery to the MTA, is to just pump all the recips to the local
> smtpd via smtplib.py.  The advantage here is that again we're MTA
> independent, but the disadvantage is that Mailman's delivery is
> synchronous with the smtpd.  We'd have to be very sure to unlock
> the list object during this transaction (but watching out for race
> conditions, locking again if failure status's are handled
> directly, etc.)  More code, more opportunity for bugs.

No no no no no no.  MailMan oeprates asynchronously of the MTA, and
because as a list server it generates unusual loads in itself, it
cannot be subject to the perfoamcen vagaries of the MTA.

Consider the case I used to commonly run into:

  Message arrives and is delivered to MailMan.

  MailMan explodes that message into a couple thousand more messages 
  (100K+ subscribers).

  MailMan attempts to hand off messages to MTA.

  MTA refuses connections as system load is too high.

  MailMan bitches.

  Meanwhile another message arrives at MailMan to be exploded.

> Comments?

Nope!

-- 
J C Lawrence                              Internet: claw@kanga.nu
----------(*)                            Internet: coder@kanga.nu
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...


Return-Path: <owner-mailman-developers@python.org>
Delivered-To: mailman-developers@dinsdale.python.org
Received: from python.org (parrot.python.org [132.151.1.90])
	by dinsdale.python.org (Postfix) with ESMTP id 568F31CD3E
	for <mailman-developers@dinsdale.python.org>; Wed, 17 Nov 1999 21:14:51 -0500 (EST)
Received: from caesar.elte.hu (caesar.elte.hu [157.181.42.42])
	by python.org (8.9.1a/8.9.1) with ESMTP id VAA20080;
	Wed, 17 Nov 1999 21:14:48 -0500 (EST)
Received: from localhost (gorgo@localhost)
	by caesar.elte.hu (8.9.0/8.9.0) with SMTP id DAA50042;
	Thu, 18 Nov 1999 03:14:16 +0100
Date: Thu, 18 Nov 1999 03:14:15 +0100 (MET)
From: Gergely Madarasz <gorgo@caesar.elte.hu>
X-Sender: gorgo@caesar.power.elte.hu
To: "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
Cc: Paul Tomblin <ptomblin@xcski.com>, J C Lawrence <claw@cp.net>,
	Klaubert Herr da Silveira <klaubert@bcb.gov.br>,
	mailman-users@python.org, mailman-developers@python.org
Subject: Re: [Mailman-Developers] Re: [Mailman-Users] optimizing mail delivery
In-Reply-To: <14387.22646.76313.150613@anthem.cnri.reston.va.us>
Message-ID: <Pine.A32.3.96.991118030855.28574H-100000@caesar.power.elte.hu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: mailman-developers-admin@python.org
Errors-To: mailman-developers-admin@python.org
X-BeenThere: mailman-developers@python.org
X-Mailman-Version: 1.1+
Precedence: bulk
List-Id: Mailman mailing list developers <mailman-developers.python.org>

On Wed, 17 Nov 1999, Barry A. Warsaw wrote:

> So do you think the Mailman way is better or worse?  I'm curious
> because I'm trying to decide whether I should port Mailman 1.0's bulk
> mailer code to the new message pipeline.

Actually I kinda like the mailman bulk mailer. Before I switched from
majordomo, I used an external bulkmail package (called from aliases, what
mailman doesn't do on delivery so I can't use it with mailman) to help out
sendmail. Changing MTA's on a high traffic site can be a real PITA, I
wouldn't like it if I had to change it because mailman can't help it out
anymore :( So I think it would be nice if you left it as an option.

-- 
Madarasz Gergely           gorgo@caesar.elte.hu         gorgo@linux.rulez.org
      It's practically impossible to look at a penguin and feel angry.
          Egy pingvinre gyakorlatilag lehetetlen haragosan nezni.
                    HuLUG: http://mlf.linux.rulez.org/



From dragondm@integral.org  Thu Nov 18 14:49:47 1999
From: dragondm@integral.org (The Dragon De Monsyne)
Date: Thu, 18 Nov 1999 08:49:47 -0600 (CST)
Subject: [Mailman-Developers] Re: [Mailman-Users] optimizing mail delivery
In-Reply-To: <14387.22646.76313.150613@anthem.cnri.reston.va.us>
Message-ID: <Pine.LNX.3.96.991118083727.15316B-100000@delta.integral.org>

On Wed, 17 Nov 1999, Barry A. Warsaw wrote:

> 
> Another alternative, which would be less work and delegates all
> delivery to the MTA, is to just pump all the recips to the local smtpd
> via smtplib.py.  The advantage here is that again we're MTA
> independent, but the disadvantage is that Mailman's delivery is
> synchronous with the smtpd.  We'd have to be very sure to unlock the
> list object during this transaction (but watching out for race
> conditions, locking again if failure status's are handled directly,
> etc.)  More code, more opportunity for bugs.

	In my own highly-hacked version of mailman that I use, I do this. 
Mailman simply drops outgoing messages into the queue directory. A
background daemon de-queues the messages and pumps them to the local MTA
via SMTP. A cronjob checks the  daemon periodically, and starts it if is
falls over. All very simple, and  has worked very reliably for me for
several months.

	-The Dragon De Monsyne



From Rick.Niess@usm.edu  Thu Nov 18 22:28:47 1999
From: Rick.Niess@usm.edu (Rick Niess)
Date: Thu, 18 Nov 1999 16:28:47 -0600 (CST)
Subject: [Mailman-Developers] Features requested...
In-Reply-To: <14384.53717.606487.837270@anthem.cnri.reston.va.us>
Message-ID: <Pine.LNX.4.10.9911181527590.30524-100000@netserver3.otr.usm.edu>

Hi All,

     Whew!  Sorry for the delay in response.  Been busybusybusy.  And
sick. <snifflesniffle> Getting better tho.  Anyway...

On Mon, 15 Nov 1999, Barry A. Warsaw wrote:
>     RN> subscribe to the list in question, please add another
>     RN> radio-button option for "Conceal yourself from subscriber
> I'd actually like to see more options at the subscription page, if not
> all the options a user can change later (that might be too cluttered
> and daunting though).

     <nod> I'd thought about asking for all of them but didn't want to
push my luck. ;-) Having "as many as is tactful and/or sensible in the
context" would be a good idea, IMHO.

>     RN> 3) Allow the system-wide admin to disable the mail->news and
>     RN> news->mail gatewaying for the whole system and/or for selected
> You can disable news->mail easily by shutting off the cron entry for
> gate_news.  Shutting off mail->news will actually be much easier to
> accomplish with the current CVS snapshot, since you can just edit out
> the ToUsenet module from the message delivery pipeline.

     <nod> I've already done this.  However, it doesn't remove the
configuration option from each list's admin pages.  But I think you knew
what I meant. ;-)

     BTW, from the sound of it, the new modular pipline structure Barry
described sounds like a winner! *lots* more flexibility. Even room for
on-the-fly user modules, etc.  One question, tho.  What was "CVS" mean?

>     RN> 5) Please setup a means by which a user can specify what
>     RN> additional addresses he/she posts from other than their
>     RN> subscription address. (For example, my campus has a mail
> Again, with a real User database, we could easily allow users to
> subscribe multiple addresses, enabling delivery to some or all of
> those addresses, and allowing postings from any of a User's known
> addresses.  Very difficult to do right now unfortunately.

     Yup.  Although I will note that Mailman's current means of dealing
with it (multiple subscriptions, only one actually delivering) is more
elegant than Majordomo's (just multiple subscriptions or a separate list
that doesn't actually handle posts)

>     RN> 6) Please setup a mechanism for a pre-made set of options to
>     RN> be used as defaults when creating new lists.
<snip>
> which really just means certain list option settings, and then just
> make those settings after the call to newlist.Create().
<snip>
> A simple hack would be to just have a bunch of classes in the newlist
> script which implement these defaults, and add a command line switch
> to invoke one of those classes on the newly created list.  If you want
> to get fancy, you could publish an API and let folks add their own
<snip>

     Oy.  OOP has never been my strong suit.  Okay, sticking with the KISS
principle, how about the desired initial "personalities" each be stored in
separate files all stored in a single subdirectory somewhere (ex,
"$prefix/personalities").  The format can be a simple
"maiman_db_variable_name='desired value'" on each line allowing for hashed
comment lines. Look familiar to some Majordomo users? <g> (Note: We'll
have to figure out a way to weed out erroneous input from here.) Then the
site admin can specify that personality with a command-line switch to
newlist.  And this could be handled right after newlist.Create(), as you
said.

     *And*, we could implement a separate switch to import a
Majordomo-style config file and map to the appropriate values, etc.  Not
hard, just tedious.  I'll be happy to sit down and write up a map of what
Majordomo values go to what Mailman values if someone can use this in the
short term...

>     RN> 8) The <body> tag is not currently setup right for error
>     RN> pages.
> I don't understand; I guess you mean the driver script is broken?  Can
> you give me more details?

     Sure.  All the normal admin and default user pages have a BODY tag
like '<BODY BGCOLOR="#ffffff">'.  But most of the erorr pages (ex, from
the archives and options CGI's) only have '<body>'.  Not terrible, just
cosmetic.  Then again, some of the error messages themselves could use a
little elaboration.  And uniformity. (Yes I know it's an opensource
project and, no, I'm not berating anyone.  Just pointing out the obvious
so it can be fixed at some point.)

>     RN>      Lastly, I'd like to note that, while I understand most of
>     RN> what's going on in the code, I don't have time ATM to sit down
>     RN> and really learn Python.  Hence, I don't have the expertise to
> Well Rick, it'll probably take you about a day to learn all the Python
> you need to become a prolific Mailman hacker!  Just be sure to try it
> /before/ you eat the turkey dinner and get all "stuffed". :)

     <giggle> We shall see... ;-) BTW, I should note that I have not
really dealt with OOP before. (That's one of the reasons Python seems so
daunting to me.) So if I've made some statments that don't make sense for
Python, now you know why.  Anyway, thanx for listening.

						~ Rick ~
--
.oooO "Man with closed Oooo.    Rick C. Niess
(   )   mouth gathers  (   )    University of Southern Miss.
 \ (      no foot!"     ) /     resnet@usm.edu
--\ )------------------(_/-------------------------------






From Rick.Niess@usm.edu  Thu Nov 18 23:11:35 1999
From: Rick.Niess@usm.edu (Rick Niess)
Date: Thu, 18 Nov 1999 17:11:35 -0600 (CST)
Subject: [Mailman-Developers] Features requested...
In-Reply-To: <19991115195334.C26336@tummy.com>
Message-ID: <Pine.LNX.4.10.9911181629160.30524-100000@netserver3.otr.usm.edu>

Hi All,

On Mon, 15 Nov 1999, Sean Reifschneider wrote:
> On Mon, Nov 15, 1999 at 05:28:55PM -0600, Rick Niess wrote:
> >4) On the membership management admin page, please setup a mechanism for
> >large lists to limit the display of user options to X number of users per
> >page.  It's a killer to try to admin large lists from slow machines with
> Hmm, it already does that.  When you select membership, it displays them
> in chunks of 10 or something.  I've upped mine to 30, and would actually
> prefer 100.

     I must have broken this somehow.  Checking into it...

> >5) Please setup a means by which a user can specify what additional
> >addresses he/she posts from other than their subscription address. (For
<snip>
> For you, it sounds like you may want to limit it to members only, but then
> allow posting from anyone who's e-mail address is "*@usm.edu" or
> "*@*.usm.edu"...  Not ideal, but it sounds like your environment doesn't
> really keep users from having a new address every week, and that's hard
> to predict.

     Ahh.  Very good points.  The latter isn't exactly feasable in a few
cases, but it's a start.

> >  - move the archives to http://host/mailman/archives/listname or provide
> >    a redirect from there to http://host/pipermail/listname.
> Correct me if I'm wrong, but can't you do that in Apache with a slightly
> modified version of the lines you already have in there to get the
> "/mailman/" and "/pipermail/" URLs to work?

     I hadn't thought of that.  Yes, it should work.  I've added a third
"Alias" line to Apache's srm.conf:

Alias /icons/ /home/httpd/icons/
Alias /pipermail/ /home/mailman/archives/public/
Alias /mailman/archives/ /home/mailman/archives/public/

     I left the old one in in case the change broke something.  As a side
note, I'll say that I was more concerned with URL uniformity than the
actual location of the archiver and data.

> >     Lastly, I'd like to note that, while I understand most of what's
> >going on in the code, I don't have time ATM to sit down and really learn
>                          ^^^^^^^^^^^^^^^^^^^
> Yeah, that seems to be the common problem these days.  Too much demand,
> too few geeks.

     Perhaps, but that's also why some of us are paid well. ;-)

						~ Rick ~
--
.oooO "Man with closed Oooo.    Rick C. Niess
(   )   mouth gathers  (   )    University of Southern Miss.
 \ (      no foot!"     ) /     resnet@usm.edu
--\ )------------------(_/-------------------------------






From andy@nachoz.com  Fri Nov 19 22:17:47 1999
From: andy@nachoz.com (Andy Harrison)
Date: Fri, 19 Nov 1999 17:17:47 -0500 (EST)
Subject: [Mailman-Developers] Feature suggestion
Message-ID: <XFMail.991119171747.andy@nachoz.com>

Just had an idea for a cool feature.  

I run a humor list and keep the filesize limit fairly low, most of the people
are dial-up of course.  I don't want to mail bomb a ton of people because
someone stupidly e-mailed the 3.2MB aliens_1.mpg file.  Right now, I pretty much
just reject it that's it.  

However, my idea is this.  What if there was some sort of mechanism in place
that stored the file in a different type of archive, and instead of mailing the
file, it included a link to click on to pick up the file instead.  That way they
could see the file size first and whatnot and know what they were getting into
before they tried to download it.


---------------------------------
E-Mail:  Andy Harrison <andy@nachoz.com>
Date:  19-Nov-99
Time:  16:46:19

This message was sent by XFMail
---------------------------------


From a.eyre@optichrome.com  Mon Nov 22 13:55:01 1999
From: a.eyre@optichrome.com (Adrian Eyre)
Date: Mon, 22 Nov 1999 13:55:01 -0000
Subject: [Mailman-Developers] Feature suggestion
In-Reply-To: <XFMail.991119171747.andy@nachoz.com>
Message-ID: <000701bf34f1$2bba3710$3acbd9c2@peridot.optichrome.com>

> However, my idea is this.  What if there was some sort of mechanism in
place
> that stored the file in a different type of archive, and instead of
mailing
> the file, it included a link to click on to pick up the file instead.

Good idea. Could it be generalised to allow all people on the mailing list
to specify a maximum attachment size. All attachments below this are
attached
to the e-mail, and any larger are replaced with links. Or maybe as a total
attachment size for each e-mail, rather than on an attachment by attachment
basis.

There is of course the issue of how long to retain the attachment on the
server
for people to pick up later. Could do it on a maximum meggage basis, and
remove
the oldest ones when space is needed for new ones.

--------------------------------------------
Adrian Eyre <mailto:a.eyre@optichrome.com>
Optichrome Computer Solutions Ltd
Maybury Road, Woking, Surrey, GU21 5HX, UK
Tel: +44 1483 740 233  Fax: +44 1483 760 644
http://www.optichrome.com
--------------------------------------------



From jmackenzie@local.ie  Mon Nov 22 14:32:40 1999
From: jmackenzie@local.ie (John MacKenzie)
Date: Mon, 22 Nov 1999 14:32:40 +0000
Subject: [Mailman-Developers] Mailman Taking on httpd UID & GID ????
In-Reply-To: <000701bf34f1$2bba3710$3acbd9c2@peridot.optichrome.com>
References: <000701bf34f1$2bba3710$3acbd9c2@peridot.optichrome.com>
Message-ID: <9911221436300C.26429@samsara.merrion.nua.net>

Hey Folks, 
I'm having a little bit of a problem, 

Having issues that when you change the config.db using the web config tool, it
writes it as UID & GID www.
Therefore Stopping mailman reading it.

I Checked a working server , and they were in the form of user : mailman/Root
Group Mailman.
permissions Being R/W R/W R.

On this machine they are user www , group www
and permissions are simply RW / RW
even if I chown and chmod the files back to normal, on next admin change, they
revert back to the above.

Any ideas?
regards
- John


-- 
John MacKenzie | Unix Systems Admin | e: mailto:jmackenzie@local.ie
___________________________________________________________________
Stay in touch your local area through Local Ireland
http://chat.local.ie/chat/index.html 
___________________________________________________________________
local ireland  | dublin  |  new york  |  http://www.local.ie



From secabeen@pobox.com  Mon Nov 22 16:24:23 1999
From: secabeen@pobox.com (Ted Cabeen)
Date: Mon, 22 Nov 1999 10:24:23 -0600
Subject: [Mailman-Developers] Missed Bounce Message
Message-ID: <199911221624.KAA27878@entropy.uchicago.edu>

Here's another missed bounce message.  

Can't SMTP server writers decide on a standard for bounces and just use it?  
Arrgh.

--
Ted Cabeen           http://www.pobox.com/~secabeen         secabeen@pobox.com
Check Website or finger for PGP Public Key        secabeen@midway.uchicago.edu
"I have taken all knowledge to be my province." -F. Bacon   cococabeen@aol.com
"Human kind cannot bear very much reality."-T.S.Eliot 73126.626@compuserve.com

------- Forwarded Message

Return-Path: ua-admin@lists.uchicago.edu
Delivery-Date: Mon Nov 22 08:23:36 1999
Return-Path: <ua-admin@lists.uchicago.edu>
Received: from einstein.uchicago.edu (einstein.uchicago.edu [128.135.132.24])
	by entropy.uchicago.edu (8.9.3/8.8.8) with ESMTP id IAA27074
	for <secabeen@entropy.uchicago.edu>; Mon, 22 Nov 1999 08:23:36 -0600 (CST)
Received: from growl.pobox.com (growl.pobox.com [208.210.124.27])
	by einstein.uchicago.edu (8.8.8+Sun/8.8.7) with ESMTP id IAA27870
	for <secabeen@control.uchicago.edu>; Mon, 22 Nov 1999 08:23:29 -0600 (CST)
Received: by growl.pobox.com (Postfix, from userid 15)
	id 0781B7EF2; Mon, 22 Nov 1999 09:23:29 -0500 (EST)
Received: from lists.uchicago.edu (lists.uchicago.edu [128.135.132.161])
	by growl.pobox.com (Postfix) with ESMTP id D09057EF2
	for <secabeen@pobox.com>; Mon, 22 Nov 1999 09:23:26 -0500 (EST)
Received: from lists (localhost [127.0.0.1])
	by lists.uchicago.edu (8.9.3/8.9.3) with ESMTP id OAA14807
	for <secabeen@pobox.com>; Mon, 22 Nov 1999 14:23:26 GMT
Received: from LEXECON.LEXECON.COM (mail.lexecon.com [199.99.121.201])
	by lists.uchicago.edu (8.9.3/8.9.3) with SMTP id OAA14781
	for <ua-admin@lists.uchicago.edu>; Mon, 22 Nov 1999 14:23:23 GMT
Message-Id: <199911221423.OAA14781@lists.uchicago.edu>
Date: Mon, 22 Nov 1999 08:22:05 CST
From: <SMTP@LEXECON.LEXECON.COM>
To: <ua-admin@lists.uchicago.edu>
Subject: Undeliverable Mail
Sender: ua-admin@lists.uchicago.edu

Attempting to deliver following mail to recipient(s):
    <brighoff@DominoFax.lexecon.com>
LEXECON.LEXECON.COM unable to connect for 1 days to recipient host.
Delivery will be attempted for a total of 3 days.

           ** Text of Mail follows **
Received: from lists.uchicago.edu [128.135.132.161] by LEXECON.LEXECON.COM (IBM VM SMTP Level 310) via TCP with SMTP ; Fri, 19 Nov 1999 20:24:31 CST
Received: from lists (localhost [127.0.0.1])
	by lists.uchicago.edu (8.9.3/8.9.3) with ESMTP id CAA08065;
	Sat, 20 Nov 1999 02:25:41 GMT
Received: from hme0.mailrouter01.sprint.ca (hme0.mailrouter01.sprint.ca [207.107.250.16])
	by lists.uchicago.edu (8.9.3/8.9.3) with ESMTP id CAA08037
	for <ua@lists.uchicago.edu>; Sat, 20 Nov 1999 02:25:36 GMT
Received: from [209.148.137.13] (spc-isp-wpg-uas-08-66.sprint.ca [209.148.137.13])
	by hme0.mailrouter01.sprint.ca (8.8.8/8.8.8) with ESMTP id VAA13278
	for <ua@lists.uchicago.edu>; Fri, 19 Nov 1999 21:25:30 -0500 (EST)
User-Agent: Microsoft Outlook Express Macintosh Edition - 5.0 (1513)
Date: Fri, 19 Nov 1999 20:25:36 -0600
Subject: Re: [UA] On the structure and arrangement of the occult
	underground
From: Rick Neal <grendel@sprint.ca>
To: <ua@lists.uchicago.edu>
Message-ID: <B45B62C0.26D%grendel@sprint.ca>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Reply-To: ua@lists.uchicago.edu
Sender: ua-admin@lists.uchicago.edu
Errors-To: ua-admin@lists.uchicago.edu
X-Mailman-Version: 1.1
Precedence: bulk
List-Id: The Unknown Armies RPG Mailing List <ua.lists.uchicago.edu>
X-BeenThere: ua@lists.uchicago.edu

<snip>


--KAA27849.943287760/entropy.uchicago.edu--




From secabeen@pobox.com  Mon Nov 22 16:28:28 1999
From: secabeen@pobox.com (Ted Cabeen)
Date: Mon, 22 Nov 1999 10:28:28 -0600
Subject: [Mailman-Developers] Mailman Taking on httpd UID & GID ????
In-Reply-To: Your message of "Mon, 22 Nov 1999 14:32:40 GMT."
 <9911221436300C.26429@samsara.merrion.nua.net>
Message-ID: <199911221628.KAA27934@entropy.uchicago.edu>

In message <9911221436300C.26429@samsara.merrion.nua.net>, John MacKenzie write
s:
>Hey Folks, 
>Having issues that when you change the config.db using the web config tool, it
>writes it as UID & GID www.
>Therefore Stopping mailman reading it.

This is probably a permissions problem.  You probably need to turn on the 
setGID bit on all the directories under ~mailman and set the group to 
mailman.  Try running bin/check_perms and see what it comes up with.  If it 
reports incorrect permissions, bin/check_perms -f should fix them.

--
Ted Cabeen           http://www.pobox.com/~secabeen         secabeen@pobox.com
Check Website or finger for PGP Public Key        secabeen@midway.uchicago.edu
"I have taken all knowledge to be my province." -F. Bacon   cococabeen@aol.com
"Human kind cannot bear very much reality."-T.S.Eliot 73126.626@compuserve.com




From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Mon Nov 22 17:01:55 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Mon, 22 Nov 1999 12:01:55 -0500 (EST)
Subject: [Mailman-Developers] Missed Bounce Message
References: <199911221624.KAA27878@entropy.uchicago.edu>
Message-ID: <14393.30467.365346.646197@anthem.cnri.reston.va.us>

>>>>> "TC" == Ted Cabeen <secabeen@pobox.com> writes:

    TC> Here's another missed bounce message.

    TC> Can't SMTP server writers decide on a standard for bounces and
    TC> just use it?  Arrgh.

Heh, that would be nice wouldn't it?  Anyway, I'm going to convert
bounce processing to the same pipeline architecture I'm using for
message delivery.  This should allow us to easily extend for new
formats, as well as start us down the road of a test framework.

I've suddenly gotten slammed with a bunch of other stuff I have to do,
so we'll see how it goes.  Maybe I'll find some time to hack over
Tgiving...

-Barry


From richard@beenz.com  Mon Nov 22 17:45:08 1999
From: richard@beenz.com (Richard Leyton)
Date: Mon, 22 Nov 1999 17:45:08 +0000
Subject: [Mailman-Developers] Mailmerge?
Message-ID: <38398124.68C372A7@beenz.com>

Hi all,

Just wondered if anybody else out there has, or is, thinking about
support for mailmerge in the mailman software? It's something I need
from my mailing software (as well as support for a dynamic user list
drawn from a database), and I'm not keen on spending £lots if mailman
could be modified...

As you can tell from my mail address, I work at beenz.com, and we will
soon be needing to e-mail our user base occasional e-mails with details
of their balances and new offers. There's nothing really out there at
the moment beyond an inhouse script we've written that just about does
the job for small volumes. We're talking several hundred thousand mails
soon enough == problems!

Any comments/suggestions? I'm bracing myself to dip into the mailman
source code - but my experience with python is (at the moment, at least)
minimal, so before starting I thought I'd check whether you feel that
it's something the mailman architecture could support, and people would
want to see (besides myself!).

Looking forward to your comments.

Regards,

Richard.

--
Richard Leyton, Unix Systems Admin - http://www.beenz.com - The web's currency
mailto:richard@beenz.com





From mats@laplaza.org  Mon Nov 22 18:03:10 1999
From: mats@laplaza.org (Mats Wichmann)
Date: Mon, 22 Nov 1999 11:03:10 -0700
Subject: [Mailman-Developers] Feature suggestion
In-Reply-To: <000701bf34f1$2bba3710$3acbd9c2@peridot.optichrome.com>
References: <XFMail.991119171747.andy@nachoz.com>
Message-ID: <3.0.6.32.19991122110310.00e7cc50@laplaza.org>

At 01:55 PM 11/22/1999 -0000, Adrian Eyre wrote:
>> However, my idea is this.  What if there was some sort of mechanism in
>> place that stored the file in a different type of archive, and instead 
>> of mailing the file, it included a link to click on to pick up the file 
>> instead.
>
>Good idea. Could it be generalised to allow all people on the mailing list
>to specify a maximum attachment size. All attachments below this are
>attached to the e-mail, and any larger are replaced with links. Or maybe 
>as a total attachment size for each e-mail, rather than on an attachment 
>by attachment basis.

Sure seems like it would be a useful feature.  I'm mostly stuck
on very slow lines, many times it's a long-distance call to get
that much. I'd like to be able to defer getting attachments -
pretty much ALL attachments - until I know at least I've got a
toll-free connection, even if it's a slow one.  Maybe there's not
enough of us so "blessed" to be worth a change, though....



From richarde@eskom.co.za  Tue Nov 23 16:30:41 1999
From: richarde@eskom.co.za (Richard Ellerbrock)
Date: Tue, 23 Nov 1999 18:30:41 +0200
Subject: [Mailman-Developers] Bug in 1.1
Message-ID: <s83add5e.063@eskom.co.za>

Since upgrading to 1.1, I am getting the following error in my error log. =
I do not know when it occurs or what leads up to it.

Nov 23 10:44:16 1999 post: Traceback (innermost last):
post:   File "/home/mailman/scripts/mailowner", line 42, in ?
post:      mlist =3D MailList.MailList(sys.argv[1])
post:   File "/home/mailman/Mailman/MailList.py", line 62, in __init__
post:      self.Load()
post:   File "/home/mailman/Mailman/MailList.py", line 804, in Load
post:      self.Lock()
post:   File "/home/mailman/Mailman/MailList.py", line 1373, in Lock
post:      self.__lock.lock()
post:   File "/home/mailman/Mailman/LockFile.py", line 186, in lock
post:      os.link(self.__lockfile, self.__tmpfname)
post: os . error :  (2, 'No such file or directory')


--
Richard Ellerbrock
richarde@eskom.co.za



From richarde@eskom.co.za  Tue Nov 23 16:47:43 1999
From: richarde@eskom.co.za (Richard Ellerbrock)
Date: Tue, 23 Nov 1999 18:47:43 +0200
Subject: [Mailman-Developers] Bug in 1.1
Message-ID: <s83ae15f.037@eskom.co.za>

Ok, did that and found 1 error:

/home/mailman/data/adm.pw permissions must be exactly 0640 (got 0100644)
(fixing)
Problems found: 1

Will monitor. Thanks for the advice.

--
Richard Ellerbrock
richarde@eskom.co.za

>>> John MacKenzie <jmackenzie@local.ie> 1999/11/23 06:35:14 >>>
That looks rather like the error I was recieving when my files/folders =
where
the incorrect GId.
Try running bin/check_perms?
Regards
- John



On Tue, 23 Nov 1999, you wrote:
> Since upgrading to 1.1, I am getting the following error in my error =
log. I do not know when it occurs or what leads up to it.
>=20
> Nov 23 10:44:16 1999 post: Traceback (innermost last):
> post:   File "/home/mailman/scripts/mailowner", line 42, in ?
> post:      mlist =3D MailList.MailList(sys.argv[1])
> post:   File "/home/mailman/Mailman/MailList.py", line 62, in __init__
> post:      self.Load()
> post:   File "/home/mailman/Mailman/MailList.py", line 804, in Load
> post:      self.Lock()
> post:   File "/home/mailman/Mailman/MailList.py", line 1373, in Lock
> post:      self.__lock.lock()
> post:   File "/home/mailman/Mailman/LockFile.py", line 186, in lock
> post:      os.link(self.__lockfile, self.__tmpfname)
> post: os . error :  (2, 'No such file or directory')
>=20
>=20
> --
> Richard Ellerbrock
> richarde@eskom.co.za=20
>=20
>=20
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org=20
> http://www.python.org/mailman/listinfo/mailman-developers=20
--=20
John MacKenzie | Unix Systems Admin | e: mailto:jmackenzie@local.ie=20
___________________________________________________________________
Stay in touch your local area through Local Ireland
http://chat.local.ie/chat/index.html=20
___________________________________________________________________
local ireland  | dublin  |  new york  |  http://www.local.ie=20




From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Wed Nov 24 17:37:29 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Wed, 24 Nov 1999 12:37:29 -0500 (EST)
Subject: [Mailman-Developers] Another round of changes
Message-ID: <14396.8793.967096.320721@anthem.cnri.reston.va.us>

Hi folks,

I have another big batch of checkins ready to go.  This set of changes
should simplify the code even more; now all delivery of non-list email
(e.g. admin notifications, post rejections, etc.) go through their own
smaller message pipeline.  Gone are contact_transport, deliver, and
dumb_deliver scripts.  Messages snagged off a newsgroup now also go
through the pipeline directly.

The advantages are that tracing through the code is much much
simpler.  I've also tried to remove all unused code, although there
may be more simplification to follow.

The downside is that currently there's no direct SMTP delivery,
although I've started to hack together a module for the message
pipeline that will do this.  It may not be as elaborate as the bulk
mailer, but it will give us back MTA independence.  You'd be able to
select either Sendmail (command line) or SMTPDirect as your MTA
delivery mechanism, but for now, you'll have to that by hacking the
code.  Fortunately, there's one file you'd need to hack to change
this.

Once again, I'm going to do the checkin, followed by more local
testing.  If all looks good, I'll make you guys guinea pigs again :)
for some wider test.

Has anybody looked at the new stuff?  If so, are you using it, even
for test lists?

My goal (dream? nightmare?) is to migrate all of the Python.Org lists
over to the new software over the Thanksgiving weekend.  We shall
see...

-Barry


From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Wed Nov 24 22:33:10 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Wed, 24 Nov 1999 17:33:10 -0500 (EST)
Subject: [Mailman-Developers] Latest changes
Message-ID: <14396.26534.282250.808841@anthem.cnri.reston.va.us>

Hey folks, I've finished checking in my latest batch of changes.
At least the basic stuff seems to be working fine, as this message
will prove if you actually see it :)

I could be asking for trouble, but I plan on moving many of the lower
volume mailing list from python.org over to this new code base.  It'll
be very interesting to see if it performs better.  I'm crossing my
fingers that it's not worse!  Narrowing it down to causes will be a
little difficult because 1) it'll be running on a much faster machine;
2) it will be using a different MTA (not sendmail); 3) the new Mailman
codebase.

Enjoy, and for you US folks, have a happy holiday,
-Barry


From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Thu Nov 25 00:35:02 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Wed, 24 Nov 1999 19:35:02 -0500 (EST)
Subject: [Mailman-Developers] Mailmerge?
References: <38398124.68C372A7@beenz.com>
Message-ID: <14396.33846.53595.701705@anthem.cnri.reston.va.us>

>>>>> "RL" == Richard Leyton <richard@beenz.com> writes:

    RL> Just wondered if anybody else out there has, or is, thinking
    RL> about support for mailmerge in the mailman software?

First time I've heard of mailmerge.  What is it, and what does it do?
    
-Barry


From dan@feld.cvut.cz  Thu Nov 25 08:40:15 1999
From: dan@feld.cvut.cz (Dan Ohnesorg)
Date: Thu, 25 Nov 1999 09:40:15 +0100 (CET)
Subject: [Mailman-Developers] Mailmerge?
In-Reply-To: <14396.33846.53595.701705@anthem.cnri.reston.va.us>
Message-ID: <Pine.LNX.4.20.9911250935150.31977-100000@poli.feld.cvut.cz>

On Wed, 24 Nov 1999, Barry A. Warsaw wrote:

> 
> >>>>> "RL" == Richard Leyton <richard@beenz.com> writes:
> 
>     RL> Just wondered if anybody else out there has, or is, thinking
>     RL> about support for mailmerge in the mailman software?
> 
> First time I've heard of mailmerge.  What is it, and what does it do?

Mailmerge is WordStar's command, it means serial mail, or personally
customized mails. Somethink like:

Dear {first-name},

Your termin for interview is on {date-time}

and then merged aganinst database with many firstnames, addresses and
meetings termins. 

Generally somethink what no one listmanager on net does. And I think it is
far away from mailmans purpose.



cheers
dan



-- 
                    ________________________________________
DDDDDD             
DD   DD                Dan Ohnesorg, supervisor on POWER     
DD  OOOO               Dan@feld.cvut.cz
DD OODDOO              Dep. of Power Engineering
DDDDDD OO              CTU FEL Prague, Bohemia
   OO  OO              work: +420 2 24352785;+420 2 24972109
    OOOO               home: +420 311 679679;+420 311 679311
                    ________________________________________

Spatril jsem ji tak jak ji panbuh stvoril.
  A stal se ateistou.



From richard@beenz.com  Thu Nov 25 10:21:18 1999
From: richard@beenz.com (Richard Leyton)
Date: Thu, 25 Nov 1999 10:21:18 +0000
Subject: [Mailman-Developers] Mailmerge?
References: <Pine.LNX.4.20.9911250935150.31977-100000@poli.feld.cvut.cz>
Message-ID: <383D0D9E.5BE1D49A@beenz.com>

Dan Ohnesorg wrote:

> On Wed, 24 Nov 1999, Barry A. Warsaw wrote:
>
> > First time I've heard of mailmerge.  What is it, and what does it do?
>
> Mailmerge is WordStar's command, it means serial mail, or personally
> customized mails. Somethink like:
>
> Dear {first-name},
>

Exactly correct. The data can be merged in from some external source, such as
a database, or a nice user list appended with additional information in some
way.

> Generally somethink what no one listmanager on net does. And I think it is
> far away from mailmans purpose.

Listserv implements this, but it's very expensive (£20k ~= $36k), and doesn't
work on Solaris or Linux.

I'd agree that it's not part of a mailmanagers /core/ functionality, but it's
functionality that'd be useful for announcement/newsletter type mailing lists
(which I suspect constitute a fair proportion of mailmans user base) and for
supporting large user bases (such as ours).

Regards,

Richard.




--
Richard Leyton, Unix Systems Admin - http://www.beenz.com - The web's currency
mailto:richard@beenz.com





From Rick.Niess@usm.edu  Thu Nov 25 23:30:03 1999
From: Rick.Niess@usm.edu (Rick Niess)
Date: Thu, 25 Nov 1999 17:30:03 -0600 (CST)
Subject: [Mailman-Developers] Found a privacy loophole...
Message-ID: <Pine.LNX.4.10.9911251723390.24729-100000@netserver3.otr.usm.edu>

Hi All,

     I just noticed something.  I have some lists which are "private", so
they don't show up in the index of lists that listinfo generates. However,
if you follow the link to the "list admin overview page", it shows all the
list names.  Not terribly useful to the average web browser, but to
someone who knows about mailman...

						~ Rick ~
--
.oooO "Man with closed Oooo.    Rick C. Niess
(   )   mouth gathers  (   )    University of Southern Miss.
 \ (      no foot!"     ) /     resnet@usm.edu
--\ )------------------(_/-------------------------------




From root@theporch.com  Fri Nov 26 13:47:44 1999
From: root@theporch.com (Phillip Porch)
Date: Fri, 26 Nov 1999 07:47:44 -0600 (CST)
Subject: [Mailman-Developers] Bug in Mailman version 1.2 (experimental) (fwd)
Message-ID: <Pine.SC5.4.10.9911260746350.16281-100000@sco.theporch.com>

---------- Forwarded message ----------
Date: Fri, 26 Nov 1999 07:26:16 -0600
From: Phillip Porch <root@theporch.com>
To: root@theporch.com
Subject: Bug in Mailman version 1.2 (experimental)

Bug in Mailman version 1.2 (experimental)
Bug in Mailman version 1.2 (experimental)

We're sorry, we hit a bug!
If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! 

Traceback:


Traceback (innermost last):
  File "/home/mailman/scripts/driver", line 108, in run_main
    pkg = __import__('Mailman.Cgi', globals(), locals(), [scriptname])
  File "/home/mailman/Mailman/Cgi/listinfo.py", line 28, in ?
    from Mailman import MailList
  File "/home/mailman/Mailman/MailList.py", line 39, in ?
    from Mailman.MailCommandHandler import MailCommandHandler
  File "/home/mailman/Mailman/MailCommandHandler.py", line 64, in ?
    option_info = {'digest'  : 0,
AttributeError: AcknowledgePosts





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

Environment variables:
      Variable Value 
      DOCUMENT_ROOT  /home  
      SERVER_ADDR  207.234.31.38  
      HTTP_ACCEPT_ENCODING  gzip, deflate  
      SERVER_PORT  8080  
      PATH_TRANSLATED  /home/bapolicy  
      REMOTE_ADDR  207.234.31.43  
      HTTP_ACCEPT_LANGUAGE  en-us  
      GATEWAY_INTERFACE  CGI/1.1  
      SERVER_NAME  sco.theporch.com  
      TZ  CST6CDT  
      HTTP_USER_AGENT  Mozilla/4.0 (compatible; MSIE 5.01; Windows 98)  
      HTTP_ACCEPT  */*  
      REQUEST_URI  /mailman/listinfo/bapolicy  
      PATH  /usr/local/bin:/usr/local/kde/bin:/bin:/etc:/usr/bin:/tcb/bin:.  
      QUERY_STRING   
      SCRIPT_FILENAME  /home/mailman/cgi-bin/listinfo  
      PATH_INFO  /bapolicy  
      HTTP_HOST  www.theporch.com:8080  
      REQUEST_METHOD  GET  
      SERVER_SIGNATURE  Apache/1.3.9 Server at sco.theporch.com Port 8080 
      SCRIPT_NAME  /mailman/listinfo  
      SERVER_ADMIN  root@sco.theporch.com  
      SERVER_SOFTWARE  Apache/1.3.9 (Unix)  
      PYTHONPATH  /home/mailman  
      REMOTE_PORT  1080  
      SERVER_PROTOCOL  HTTP/1.1  
      HTTP_CONNECTION  Keep-Alive  





From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Fri Nov 26 15:13:57 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Fri, 26 Nov 1999 10:13:57 -0500 (EST)
Subject: [Mailman-Developers] Bug in Mailman version 1.2 (experimental) (fwd)
References: <Pine.SC5.4.10.9911260746350.16281-100000@sco.theporch.com>
Message-ID: <14398.41909.845674.829105@anthem.cnri.reston.va.us>

If you're using the latest CVS snapshot, be sure to re-run configure
before doing a "make install".  You can just run config.status if you
still have that around.  You need to regenerate Mailman/Defaults.py
from the Mailman/Defaults.py.in file.

-Barry


From bwarsaw@python.org  Fri Nov 26 23:27:31 1999
From: bwarsaw@python.org (Barry A. Warsaw)
Date: Fri, 26 Nov 1999 18:27:31 -0500 (EST)
Subject: [Mailman-Developers] Re: [Mailman-Users] optimizing mail delivery
References: <14387.22646.76313.150613@anthem.cnri.reston.va.us>
 <Pine.LNX.3.96.991118083727.15316B-100000@delta.integral.org>
Message-ID: <14399.5987.612724.582341@anthem.cnri.reston.va.us>

    Dragon> 	In my own highly-hacked version of mailman that I use,
    Dragon> I do this.  Mailman simply drops outgoing messages into
    Dragon> the queue directory. A background daemon de-queues the
    Dragon> messages and pumps them to the local MTA via SMTP. A
    Dragon> cronjob checks the daemon periodically, and starts it if
    Dragon> is falls over. All very simple, and has worked very
    Dragon> reliably for me for several months.

This would make a nice addition to Mailman, and probably wouldn't be
hard to port to the new message pipeline model.  How'd you like to
look into that?

-Barry


From dragondm@integral.org  Sat Nov 27 10:36:55 1999
From: dragondm@integral.org (The Dragon De Monsyne)
Date: Sat, 27 Nov 1999 04:36:55 -0600 (CST)
Subject: [Mailman-Developers] Re: optimizing mail delivery
In-Reply-To: <14399.5987.612724.582341@anthem.cnri.reston.va.us>
Message-ID: <Pine.LNX.3.96.991127042426.30741A-100000@delta.integral.org>

On Fri, 26 Nov 1999, Barry A. Warsaw wrote:


>     Dragon> 	In my own highly-hacked version of mailman that I use,
>     Dragon> I do this.  Mailman simply drops outgoing messages into
>     Dragon> the queue directory. A background daemon de-queues the
>     Dragon> messages and pumps them to the local MTA via SMTP. A
>     Dragon> cronjob checks the daemon periodically, and starts it if
>     Dragon> is falls over. All very simple, and has worked very
>     Dragon> reliably for me for several months.
> 
> This would make a nice addition to Mailman, and probably wouldn't be
> hard to port to the new message pipeline model.  How'd you like to
> look into that?

	Sure! I'd be happy to. Probably not today, as I have a rather bad
case of the flu, and right at the moment sitting upright for any length
of time is rewarded with nausea and a blinding headache :P,  but mebbe on
sunday I'll be up to it & I'll pull the CVS and see what I can do. It
should  be fairly simple to port. 

PS: good job for doing this cleanup, this is something that's been needed
for awhile.

	-The Dragon De Monsyne



From petrilli@amber.org  Sat Nov 27 14:40:42 1999
From: petrilli@amber.org (Christopher Petrilli)
Date: Sat, 27 Nov 1999 09:40:42 -0500
Subject: [Mailman-Developers] Mailmerge?
In-Reply-To: <383D0D9E.5BE1D49A@beenz.com>; from richard@beenz.com on Thu, Nov 25, 1999 at 10:21:18AM +0000
References: <Pine.LNX.4.20.9911250935150.31977-100000@poli.feld.cvut.cz> <383D0D9E.5BE1D49A@beenz.com>
Message-ID: <19991127094042.A11461@trump.amber.org>

Richard Leyton [richard@beenz.com] wrote:
> Dan Ohnesorg wrote:
> 
> > On Wed, 24 Nov 1999, Barry A. Warsaw wrote:
> >
> > > First time I've heard of mailmerge.  What is it, and what does it do?
> >
> > Mailmerge is WordStar's command, it means serial mail, or personally
> > customized mails. Somethink like:
> >
> > Dear {first-name},
> >
> 
> Exactly correct. The data can be merged in from some external source, such as
> a database, or a nice user list appended with additional information in some
> way.

I suspect that this would be nearly impossible unless you were merging in
pieces of information that Mailman already had... otherwise you'd have a huge
data corrolation piece.  ONe day, Mailman will actually have a more real
database behind it that lets you keep arbitrary data about each person, rather
than just their email.

Chris
-- 
| Christopher Petrilli
| petrilli@amber.org


From claw@kanga.nu  Mon Nov 29 04:19:40 1999
From: claw@kanga.nu (claw@kanga.nu)
Date: Sun, 28 Nov 1999 20:19:40 -0800
Subject: [Mailman-Developers] Mailman, hard links and the Openwall (fw)
Message-ID: <E11sIHs-0005NJ-00@koala.kanga.nu>

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <20661.943849179.1@kanga.nu>

This seems a little offbeat, but should be addressed:

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


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

X-Envelope-From: debian-devel-request@lists.debian.org Sun Nov 28 13:59:43 1999
Return-path: <debian-devel-request@lists.debian.org>
Envelope-to: claw@localhost
Delivery-date: Sun, 28 Nov 1999 13:59:43 -0800
Received: from localhost ([127.0.0.1] ident=claw)
	by koala.kanga.nu with esmtp (Exim 2.12 #1)
	id 11sCMB-00048o-00
	for claw@localhost; Sun, 28 Nov 1999 13:59:43 -0800
Received: from kanga.nu
	by fetchmail-4.5.8 POP3
	for <claw/localhost> (single-drop); Sun, 28 Nov 1999 13:59:43 PST
Received: from murphy.debian.org [209.41.108.199] 
	by kanga.nu with smtp (Exim 3.03 #1 (Debian))
	id 11sCOl-0004fJ-00; Sun, 28 Nov 1999 14:02:23 -0800
Received: (qmail 12190 invoked by uid 38); 28 Nov 1999 22:01:22 -0000
Resent-Date: 28 Nov 1999 22:01:22 -0000
Resent-Cc: recipient list not shown: ;
X-Envelope-Sender: grendel@vip.net.pl
Date: Sun, 28 Nov 1999 23:01:30 +0100
From: Marek Habersack <grendel@vip.net.pl>
To: debian-devel@lists.debian.org
Subject: Mailman, hard links and the Openwall
Message-ID: <19991128230130.A20329@vip.net.pl>
Reply-To: grendel@vip.net.pl
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
	protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE"
User-Agent: Mutt/1.0i
Organization: I just...
Resent-Message-ID: <PxjSiD.A.M-C.xYaQ4@murphy>
Resent-From: debian-devel@lists.debian.org
X-Mailing-List: <debian-devel@lists.debian.org> archive/latest/50197
X-Loop: debian-devel@lists.debian.org
Precedence: list
Resent-Sender: debian-devel-request@lists.debian.org


--Kj7319i9nmIyA2yE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Hi *,

  Some of you probably know the Solar Designer's OpenWall security patches
to the Linux kernel. One of the features of these patches is the ability to
prevent users from creating symlinks and hardlinks in /tmp to files they
don't own. Some time ago my Mailman stopped working and I didn't associate
the security warning messages popping up on a screen with the Solar
Designer's patch which I have just applied to the 2.2.13 kernle. Recently,
however, I decided to look at what might be the problem causing Mailman to
fail. It turns out that Mailman uses hard links in /tmp to files in the
/var/lib/mailman/lists/listname/* files and also to lock some other files.
The problem is that those files are owned by root.list with mode 664
(mostly) and the httpd daemon (Roxen in my case) runs the Mailman scripts as
nobody or list. The Solar Designer's code refuses creating sym- and
hardlinks to those files and Python raises an exception causing Mailman to
abort. Now, I see no reason for the files to be owned by root.list - after
making the httpd execute Mailman scripts with UID 38 (list) and changing the
ownership of the entire Mailman director tree to list.list everything
started to work smoothly again. Therefore, I think the postinst Mailman
script should change the ownership of the files to list.list.
 =20
thanks,

marek

--Kj7319i9nmIyA2yE
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEAREBAAYFAjhBpjoACgkQq3909GIf5urX8wCghi0X0FVGOGG4a9DCtQo3UIoh
g3QAn1DJByzpbwqXBfdLYfc79Fd9I79I
=7QYb
-----END PGP SIGNATURE-----

--Kj7319i9nmIyA2yE--


-- 
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



------- =_aaaaaaaaaa0--


From Rick.Niess@usm.edu  Thu Nov 25 23:30:03 1999
From: Rick.Niess@usm.edu (Rick Niess)
Date: Thu, 25 Nov 1999 17:30:03 -0600 (CST)
Subject: [Mailman-Developers] Found a privacy loophole...
Message-ID: <Pine.LNX.4.10.9911251723390.24729-100000@netserver3.otr.usm.edu>

Hi All,

     I just noticed something.  I have some lists which are "private", so
they don't show up in the index of lists that listinfo generates. However,
if you follow the link to the "list admin overview page", it shows all the
list names.  Not terribly useful to the average web browser, but to
someone who knows about mailman...

						~ Rick ~
--
.oooO "Man with closed Oooo.    Rick C. Niess
(   )   mouth gathers  (   )    University of Southern Miss.
 \ (      no foot!"     ) /     resnet@usm.edu
--\ )------------------(_/-------------------------------





From claw@kanga.nu  Mon Nov 29 06:34:18 1999
From: claw@kanga.nu (claw@kanga.nu)
Date: Sun, 28 Nov 1999 22:34:18 -0800
Subject: [Mailman-Developers] Found a privacy loophole...
In-Reply-To: Message from Rick Niess <rniess@netserver3.otr.usm.edu>
 of "Thu, 25 Nov 1999 17:30:03 CST." <Pine.LNX.4.10.9911251723390.24729-100000@netserver3.otr.usm.edu>
Message-ID: <E11sKOB-0005el-00@koala.kanga.nu>

On Thu, 25 Nov 1999 17:30:03 -0600 (CST) 
Rick Niess <rniess@netserver3.otr.usm.edu> wrote:

> Hi All, I just noticed something.  I have some lists which are
> "private", so they don't show up in the index of lists that
> listinfo generates. However, if you follow the link to the "list
> admin overview page", it shows all the list names.  Not terribly
> useful to the average web browser, but to someone who knows about
> mailman...

The most they can find out from the admin page without a list
password is the fact that a name exists and thereby the knowledge of
how to send administration and attempted post messages to the list.

If that is a problem, then you have larger problems in that you are
implicitly relying on security thru obscurity.  There is nothing
that that web page can tell anybody that someone merely watching the
mail traffic in and out of your site can't also determine.

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From fil@bok.net  Mon Nov 29 11:17:12 1999
From: fil@bok.net (Fil)
Date: Mon, 29 Nov 1999 12:17:12 +0100 (MET)
Subject: [Mailman-Developers] no passord on subscription page ... and others
Message-ID: <Pine.LNX.3.96.991129120802.978A-100000@orwell>

Hi mailman developers,

it seems to me that to request a password from the subscribing page is
confusing, overkill, and useless... when you can generate the password on
the fly for the user. So the patch would be in Mailman/Cgi/subscribe.py

>>>>>>>>>>>>>>>>>>>>>>>>>>
    if not form.has_key("pw") or not form.has_key("pw-conf"):
#################################### patch  fil@bok.net 27/11/1999
        pw  = Utils.MakeRandomPassword()
        pwc = pw
#        error = 1
#        results = (results
#             + "You must supply a valid password, and confirm it.<br>")
<<<<<<<<<<<<<<<<<<<<<<<<<<<

and one would have to modify the standard HTML template too. But maybe
this could be toggled from the list-admin page ?

Secondly: is it possible that the mail-command analyzer catches messages
sent to the list-on@server and list-off@server addresses and processes
them as subscribe/unsubscribe commands ?  This would emulate the LetterRip
behaviour (www.fogcity.com), which is quite nice in this respect.

Thirdly: I'd like people to be unsubscribed w/o their password. Some users
tend to be annoying when then want to leave.

Fourthly: I'm trying to see how to add a user-name field in the
subscribers database... seems alot of work. Is this a planned feature ?


Well, that's all for now; keep on the good work!



From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Mon Nov 29 19:52:15 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Mon, 29 Nov 1999 14:52:15 -0500 (EST)
Subject: [Mailman-Developers] Mailman, hard links and the Openwall (fw)
References: <E11sIHs-0005NJ-00@koala.kanga.nu>
Message-ID: <14402.55663.805571.378280@anthem.cnri.reston.va.us>

>>>>> "claw" ==   <claw@kanga.nu> writes:

    claw> This seems a little offbeat, but should be addressed:

README.LINUX hints at a similar issue.  Would someone with more direct
experience please rewrite or extend README.LINUX to describe what
someone with the OpenWall security patches ought to do?

Thanks,
-Barry


From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Mon Nov 29 20:08:50 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Mon, 29 Nov 1999 15:08:50 -0500 (EST)
Subject: [Mailman-Developers] no passord on subscription page ... and others
References: <Pine.LNX.3.96.991129120802.978A-100000@orwell>
Message-ID: <14402.56658.739390.667156@anthem.cnri.reston.va.us>

>>>>> "F" == Fil  <fil@bok.net> writes:

    F> it seems to me that to request a password from the subscribing
    F> page is confusing, overkill, and useless... when you can
    F> generate the password on the fly for the user. So the patch
    F> would be in Mailman/Cgi/subscribe.py

I'd rather make the password field optional, and generate a password
for them if it's missing.  In this case, you'd have to force a welcome
message so that the user will receive the password.

    F> Secondly: is it possible that the mail-command analyzer catches
    F> messages sent to the list-on@server and list-off@server
    F> addresses and processes them as subscribe/unsubscribe commands
    F> ?  This would emulate the LetterRip behaviour
    F> (www.fogcity.com), which is quite nice in this respect.

This probably wouldn't be hard to add, although I like list-add@
and list-remove@ or some such.

-Barry


From claw@kanga.nu  Mon Nov 29 20:20:34 1999
From: claw@kanga.nu (claw@kanga.nu)
Date: Mon, 29 Nov 1999 12:20:34 -0800
Subject: [Mailman-Developers] no passord on subscription page ... and others
In-Reply-To: Message from Fil <fil@bok.net>
 of "Mon, 29 Nov 1999 12:17:12 +0100." <Pine.LNX.3.96.991129120802.978A-100000@orwell>
Message-ID: <E11sXHm-0006lr-00@koala.kanga.nu>

On Mon, 29 Nov 1999 12:17:12 +0100 (MET) 
Fil  <fil@bok.net> wrote:

> it seems to me that to request a password from the subscribing
> page is confusing, overkill, and useless... when you can generate
> the password on the fly for the user. 

Many users like to control their passwords and so wish to select
them themselves (usually so that they can use the same password in
many places, but that's another matter).  Using this patch forces
such users to subscribe, confirm their subscription and _then_ go
log in with their assigned password to change it to their
preference.  

I don't see the point in being that righteous about what other
people use for their passwords.

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From jam@jamux.com  Mon Nov 29 23:33:03 1999
From: jam@jamux.com (John A. Martin)
Date: Mon, 29 Nov 1999 18:33:03 -0500
Subject: [Mailman-Developers] Nick Rout: RE: WebMail/WebAdmin can run on Postfix ?
Message-ID: <19991129233306.ED410481C@athene.jamux.com>

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

Name clash?

	jam

- ------- Forwarded Message

From: Nick Rout <nickr@ihug.co.nz>
To: "postfix-users@postfix.org" <postfix-users@postfix.org>
Subject: RE: WebMail/WebAdmin can run on Postfix ?
Date: Tue, 30 Nov 1999 09:11:41 +1300

There is Endymion mail man http://www.endymion.com/products/mailman/ . My 
isp (www.ihug.co.nz) uses it to give their users web based access to pop 
email, if thats what u are after. requires perl & cgi. Its not free however 
:-)

[[ ... ]]

- ------- End of Forwarded Message

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: By Mailcrypt 3.5.4 and Gnu Privacy Guard <http://www.gnupg.org/>

iD8DBQE4Qw0iUEvv1b/iXy8RAhJLAJ46sYZuw6p1IShbN/5KCZjMnUCYzgCeKaxt
KUUEyDHhRKZ00J6LQG7SONA=
=QY6p
-----END PGP SIGNATURE-----


From lindsey@ncsa.uiuc.edu  Mon Nov 29 23:43:06 1999
From: lindsey@ncsa.uiuc.edu (Christopher Lindsey)
Date: Mon, 29 Nov 1999 17:43:06 -0600 (CST)
Subject: [Mailman-Developers] Nick Rout: RE: WebMail/WebAdmin can run on Postfix ?
In-Reply-To: <19991129233306.ED410481C@athene.jamux.com> from "John A. Martin" at Nov 29, 99 06:33:03 pm
Message-ID: <199911292343.RAA14375@ferret.ncsa.uiuc.edu>

> Name clash?

Yes, but no...  :)

http://dinsdale.python.org/pipermail/mailman-users/1998-November/002888.html

Chris

> From: Nick Rout <nickr@ihug.co.nz>
> 
> There is Endymion mail man http://www.endymion.com/products/mailman/ . My 
> isp (www.ihug.co.nz) uses it to give their users web based access to pop 
> email, if thats what u are after. requires perl & cgi. Its not free however 


From ricardo@miss-janet.com  Mon Nov 29 20:59:33 1999
From: ricardo@miss-janet.com (Ricardo Kustner)
Date: Mon, 29 Nov 1999 21:59:33 +0100
Subject: [Mailman-Developers] thoughts on http+smtp
Message-ID: <19991129215933.G501@miss-janet.com>

Hi,

First of all, I mentioned this on this list earlier but back then I didnt
get much response so I'm trying it again, now the list seems a bit more
active :)
Anyway, i'm running mailman on a P100 with 64mb... even though that isn't
much compared to today's hardware... it still suffies for most of the needs
(for example, apache is running smoothly on it with quite many hits... with peeks
of 5,000 hits/hour ...there's a mysql server on it too.. handling most of those
requests through auth_mysql).
To get to the point, mailman is the best mailinglist software i found
so far, but one thing that still kinda bothers me sinds the beginning
is that when using the admin pages to approved messages which are held
for approval, the python cgi scripts won't finnish the http request
untill all messages have been feed to the MTA... i'm running a list
with 1,500+ subscribers and when about 20 messages are being approved
at the same time, that means the server will get a huge load in a short
period of time. Also, since the cgi script doesn't finnish untill the
messages have been submitted to the MTA, sometimes the http request
just times out... I personally think that a cgi script do his work
*quickly* and finnish outputting the html asap...
I think it would be great if the admindb.py could just 'mark' messages
to be delivered and a background process handles the dirty work, instead
of having cgi scripts doing the SMTP connections...
and i still vote for having mail, which is held for approval, in a seperate
directory instead of putting them in a python database...
well these are just some thoughts, i hope can start some discussion on it :)

Ricardo.

--



From ricardo@miss-janet.com  Mon Nov 29 21:08:10 1999
From: ricardo@miss-janet.com (Ricardo Kustner)
Date: Mon, 29 Nov 1999 22:08:10 +0100
Subject: [Mailman-Developers] Missed Bounce Message
In-Reply-To: <199911221624.KAA27878@entropy.uchicago.edu>; from secabeen@pobox.com on Mon, Nov 22, 1999 at 10:24:23AM -0600
References: <199911221624.KAA27878@entropy.uchicago.edu>
Message-ID: <19991129220810.H501@miss-janet.com>

On Mon, Nov 22, 1999 at 10:24:23AM -0600, Ted Cabeen wrote:
> Here's another missed bounce message.  
> Can't SMTP server writers decide on a standard for bounces and just use it?  
> Arrgh.
tell me about it... i've spend too many hours in my life trying to unsubscribe
list members who were bouncing their mail... going on a holiday is out of the
question of you are the owner of a mailinglist ;)
i don't understand why it seems that with all the standards on the internet,
nobody seems to have tried to set a standard on bouncing email (AFAIK)... every new
MTA creates his own exotic version... not mentioning the fact that some
mailers (AOL,hotmail) seem to have several different variations of bouncing
mail...
*sigh* i had to get that off my back :)

Ricardo.

--



From claw@kanga.nu  Tue Nov 30 01:30:13 1999
From: claw@kanga.nu (claw@kanga.nu)
Date: Mon, 29 Nov 1999 17:30:13 -0800
Subject: [Mailman-Developers] Missed Bounce Message
In-Reply-To: Message from Ricardo Kustner <ricardo@miss-janet.com>
 of "Mon, 29 Nov 1999 22:08:10 +0100." <19991129220810.H501@miss-janet.com>
Message-ID: <E11sc7S-0004Eh-00@koala.kanga.nu>

On Mon, 29 Nov 1999 22:08:10 +0100 
Ricardo Kustner <ricardo@miss-janet.com> wrote:

> On Mon, Nov 22, 1999 at 10:24:23AM -0600, Ted Cabeen wrote:
>> Here's another missed bounce message.  Can't SMTP server writers
>> decide on a standard for bounces and just use it?  Arrgh.

> tell me about it... 

As there is no standard format for bounce messages, and even if
there were one we'd still be suffering with non-standard ones due to 
the great many legacy MTAs as well as the many sites with locally
customised bounce messages, another approach is needed.

The most commonly recommended solution is VERP.  The problem with
VERP is that it places a very high load on the local MTA as well as
any distribution management you may have set up (eg domain routing).
The approach I took back when I was writing my own mailing list
server was a middle ground with the intent of avoiding most of
VERP's bandwidth concerns while retaining many of its advantages:

  The list server emitted messages in bundles of 100 RCPT TOs in the
  normal manner except for every Nth message.

  For every N'th message (and this encluded digests), that message
was sent individually to every subscriber with a custom header field
added.

The custom header field was ala:

  x-bounce-detect: ListMgr <listname> <subscriber_address> <count> <score>

Where 'count' was just a number that incremented every time N rolled
around.  It was used to detect how old this bounce was and if there
had been any other "bounce-sensitive" messages emitted since that
one was received.  The 'score' value was just a tracking value
indicating how close that subscriber was to being unsubscribed.

The intent was that the custom header could be found in the copy of
the original email encluded in the bounce message, and could be
easily analysed to find the name of the list, the original
subscriber's address (in case of the message being forwarded),
etc. I then just scanned bounce messages for the header, and kept
track of how often and rapidly each subscriber bounced messages, and 
if the rate exceeded a certain value, unsubscribing that member.

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From fil@bok.net  Tue Nov 30 08:32:01 1999
From: fil@bok.net (Fil)
Date: Tue, 30 Nov 1999 09:32:01 +0100 (MET)
Subject: [Mailman-Developers] no passord on subscription page ... and others
In-Reply-To: <E11sXHm-0006lr-00@koala.kanga.nu>
Message-ID: <Pine.LNX.3.96.991130092943.17377A-100000@orwell>

On Mon, 29 Nov 1999 claw@kanga.nu wrote:
> On Mon, 29 Nov 1999 12:17:12 +0100 (MET) 
> Fil  <fil@bok.net> wrote:
> 
> > it seems to me that to request a password from the subscribing
> > page is confusing, overkill, and useless... when you can generate
> > the password on the fly for the user. 
> 
> Many users like to control their passwords and so wish to select
> them themselves (usually so that they can use the same password in
> many places, but that's another matter).  Using this patch forces
> such users to subscribe, confirm their subscription and _then_ go
> log in with their assigned password to change it to their
> preference.  
> 
> I don't see the point in being that righteous about what other
> people use for their passwords.

No. I don'(t care what people use for their password; I just mean that the
password in this case is not that important, and to put it up front like
it is now can lead to : 
a) people giving their POP password
b) people being deterred from subscribing by the apparent complexity and
the burden of having to remember a new password





From fil@bok.net  Tue Nov 30 08:38:39 1999
From: fil@bok.net (Fil)
Date: Tue, 30 Nov 1999 09:38:39 +0100 (MET)
Subject: [Mailman-Developers] no passord on subscription page ... and others
In-Reply-To: <14402.56658.739390.667156@anthem.cnri.reston.va.us>
Message-ID: <Pine.LNX.3.96.991130093817.17377B-100000@orwell>

On Mon, 29 Nov 1999, Barry A. Warsaw wrote:
> >>>>> "F" == Fil  <fil@bok.net> writes:
> 
>     F> it seems to me that to request a password from the subscribing
>     F> page is confusing, overkill, and useless... when you can
>     F> generate the password on the fly for the user. So the patch
>     F> would be in Mailman/Cgi/subscribe.py
> 
> I'd rather make the password field optional, and generate a password
> for them if it's missing.  In this case, you'd have to force a welcome
> message so that the user will receive the password.

Yes this would be great

>     F> Secondly: is it possible that the mail-command analyzer catches
>     F> messages sent to the list-on@server and list-off@server
>     F> addresses and processes them as subscribe/unsubscribe commands
>     F> ?  This would emulate the LetterRip behaviour
>     F> (www.fogcity.com), which is quite nice in this respect.
> 
> This probably wouldn't be hard to add, although I like list-add@
> and list-remove@ or some such.

Fine with me ;)



From a.eyre@optichrome.com  Tue Nov 30 09:55:38 1999
From: a.eyre@optichrome.com (Adrian Eyre)
Date: Tue, 30 Nov 1999 09:55:38 -0000
Subject: [Mailman-Developers] NT Port
Message-ID: <001401bf3b19$0dd75420$3acbd9c2@peridot.optichrome.com>

Is there, or is anyone working on an NT port of Mailman?
If not, I may start working on one myself.

--------------------------------------------
Adrian Eyre <mailto:a.eyre@optichrome.com>
Optichrome Computer Solutions Ltd
Maybury Road, Woking, Surrey, GU21 5HX, UK
Tel: +44 1483 740 233  Fax: +44 1483 760 644
http://www.optichrome.com 
--------------------------------------------



From Rick.Niess@usm.edu  Tue Nov 30 16:39:08 1999
From: Rick.Niess@usm.edu (Rick Niess)
Date: Tue, 30 Nov 1999 10:39:08 -0600 (CST)
Subject: [Mailman-Developers] Found a privacy loophole...
In-Reply-To: <E11sKOB-0005el-00@koala.kanga.nu>
Message-ID: <Pine.LNX.4.10.9911301030020.27149-100000@netserver3.otr.usm.edu>

On Sun, 28 Nov 1999 claw@kanga.nu wrote:
> On Thu, 25 Nov 1999 17:30:03 -0600 (CST) 
> Rick Niess <rniess@netserver3.otr.usm.edu> wrote:
> > Hi All, I just noticed something.  I have some lists which are
> > "private", so they don't show up in the index of lists that
> > listinfo generates. However, if you follow the link to the "list
> > admin overview page", it shows all the list names.  Not terribly
> The most they can find out from the admin page without a list
> password is the fact that a name exists and thereby the knowledge of
> how to send administration and attempted post messages to the list.

     Whoah.  All I was pointing out was that attempting to hide the
existence of a list to those viewing the listinfo index (by turning off
the Advertize option) isn't entirely bulletproof.  The listinfo index page
specifically tells them how to get to the pages for lists that they know
exist but aren't listed there, and then it provides a link to the list
admin overview page which lists all existing lists, hidden or not.

     This isn't serious, or at least not on a system-wide level.  Just
possibly embarrasing to a list admin.  And Barry has already noted that
it's a known bug.  FYI...

						~ Rick ~
--
.oooO "Man with closed Oooo.    Rick C. Niess
(   )   mouth gathers  (   )    University of Southern Miss.
 \ (      no foot!"     ) /     resnet@usm.edu
--\ )------------------(_/-------------------------------




From secabeen@pobox.com  Tue Nov 30 18:08:24 1999
From: secabeen@pobox.com (Ted Cabeen)
Date: Tue, 30 Nov 1999 12:08:24 -0600
Subject: [Mailman-Developers] Found a privacy loophole...
In-Reply-To: Your message of "Tue, 30 Nov 1999 10:39:08 CST."
 <Pine.LNX.4.10.9911301030020.27149-100000@netserver3.otr.usm.edu>
Message-ID: <199911301808.MAA22790@entropy.uchicago.edu>

In message <Pine.LNX.4.10.9911301030020.27149-100000@netserver3.otr.usm.edu>, R
ick Niess writes:
>     Whoah.  All I was pointing out was that attempting to hide the
>existence of a list to those viewing the listinfo index (by turning off
>the Advertize option) isn't entirely bulletproof.  The listinfo index page
>specifically tells them how to get to the pages for lists that they know
>exist but aren't listed there, and then it provides a link to the list
>admin overview page which lists all existing lists, hidden or not.

Are you sure that your site works that way?  If a list is unadvertised, 
then it shouldn't show up on either the listinfo or admin pages.  Are you 
really seeing all the lists on the server on the admin page?  

--
Ted Cabeen           http://www.pobox.com/~secabeen         secabeen@pobox.com
Check Website or finger for PGP Public Key        secabeen@midway.uchicago.edu
"I have taken all knowledge to be my province." -F. Bacon   cococabeen@aol.com
"Human kind cannot bear very much reality."-T.S.Eliot 73126.626@compuserve.com




From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Tue Nov 30 21:09:21 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Tue, 30 Nov 1999 16:09:21 -0500 (EST)
Subject: [Mailman-Developers] Missed Bounce Message
References: <ricardo@miss-janet.com>
 <19991129220810.H501@miss-janet.com>
 <E11sc7S-0004Eh-00@koala.kanga.nu>
Message-ID: <14404.15617.893406.135943@anthem.cnri.reston.va.us>

>>>>> "claw" ==   <claw@kanga.nu> writes:

    claw> As there is no standard format for bounce messages, and even
    claw> if there were one we'd still be suffering with non-standard
    claw> ones due to the great many legacy MTAs as well as the many
    claw> sites with locally customised bounce messages, another
    claw> approach is needed.

Well, there is DSN, but you're essentially right since most MTA don't
seem to do DSN at all.  I think there's even some controversy over the
complexity of DSN bounce formats, so you're essentially left with a
plethora of formats that you have to parse.

    claw> The most commonly recommended solution is VERP.  The problem
    claw> with VERP is that it places a very high load on the local
    claw> MTA as well as any distribution management you may have set
    claw> up (eg domain routing).  The approach I took back when I was
    claw> writing my own mailing list server was a middle ground with
    claw> the intent of avoiding most of VERP's bandwidth concerns
    claw> while retaining many of its advantages:

For a while now I've been thinking that we could do this kind of
VERP-like custom messages for the password reminders.  Those we
already have to craft specially for each recipient, so why not include
an easily detected header, then catch those bounces and scan them?

-Barry


From jfesler@gigo.com  Tue Nov 30 21:29:57 1999
From: jfesler@gigo.com (jfesler@gigo.com)
Date: Tue, 30 Nov 1999 13:29:57 -0800 (PST)
Subject: [Mailman-Developers] Missed Bounce Message
In-Reply-To: <14404.15617.893406.135943@anthem.cnri.reston.va.us>
Message-ID: <Pine.BSF.4.10.9911301328400.36918-100000@heaven.gigo.com>

> For a while now I've been thinking that we could do this kind of
> VERP-like custom messages for the password reminders.  Those we
> already have to craft specially for each recipient, so why not include
> an easily detected header, then catch those bounces and scan them?

Note that some mail servers refuse to send the message body back (grrr).
If you do it as the envelope you're guaranteed to be able to recognize it,
whether or not the body bounces..

[I'm also highly in favor of the at-password-time bounce checking - keeps
load light-ish for most list traffic, and just the occasional
reminder/probe]




From claw@kanga.nu  Tue Nov 30 21:38:10 1999
From: claw@kanga.nu (claw@kanga.nu)
Date: Tue, 30 Nov 1999 13:38:10 -0800
Subject: [Mailman-Developers] Missed Bounce Message
In-Reply-To: Message from "Barry A. Warsaw" <bwarsaw@cnri.reston.va.us>
 of "Tue, 30 Nov 1999 16:09:21 EST." <14404.15617.893406.135943@anthem.cnri.reston.va.us>
Message-ID: <E11suyQ-0008RU-00@koala.kanga.nu>

On Tue, 30 Nov 1999 16:09:21 -0500 (EST) 
Barry A Warsaw <bwarsaw@cnri.reston.va.us> wrote:

> For a while now I've been thinking that we could do this kind of
> VERP-like custom messages for the password reminders.  Those we
> already have to craft specially for each recipient, so why not
> include an easily detected header, then catch those bounces and
> scan them?

Not a bad idea at all!

I chose a selectable VERP-ish window as I wanted to be able to
tailor the sensitivity to the normal rate of list traffic: It
wouldn't be surprising to get 10 bounces a day from one member if
your post averages a couple hundred posts a day and you dine one
VERP-ish per 10 messages...

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From jafo@tummy.com  Tue Nov 30 21:50:02 1999
From: jafo@tummy.com (Sean Reifschneider)
Date: Tue, 30 Nov 1999 14:50:02 -0700
Subject: [Mailman-Developers] Missed Bounce Message
In-Reply-To: <Pine.BSF.4.10.9911301328400.36918-100000@heaven.gigo.com>; from jfesler@gigo.com on Tue, Nov 30, 1999 at 01:29:57PM -0800
References: <14404.15617.893406.135943@anthem.cnri.reston.va.us> <Pine.BSF.4.10.9911301328400.36918-100000@heaven.gigo.com>
Message-ID: <19991130145001.F989@tummy.com>

On Tue, Nov 30, 1999 at 01:29:57PM -0800, jfesler@gigo.com wrote:
>[I'm also highly in favor of the at-password-time bounce checking - keeps
>load light-ish for most list traffic, and just the occasional
>reminder/probe]

Yeah, that sounds like a good idea, but are you going to kick them off after
one bounce, or wait several months before kicking them off?  Or would a
failure of that message cause probes to begin being sent, or the address
to be marked as "suspect" and use VERPs for delivery?

I'm imagining something like a binary search.  You *CAN* use a header or
VERP while still sending batches, you just have to realize that a VERP
is associated with a particular SET of addresses.  You mark these as
suspect, and future deliveries to these addresses aren't batched.
The back-off time on these addresses being marked as suspect can be
relatively low, but probably should be by number of messages sent, not
by hours (for low volume lists).  Maybe 3 messages or less.

So, if you have three addresses bouncing from among 10k addresses, and
your chunk size is 20, you only send out about an extra 150 messages
to determin exactly where the bounce is.

This seems more efficient than sending probes regularly (particularly for
huge lists), and more pro-active than waiting till the end of the month.

I'd be interested in working on such a thing.  My question though is,
what's the preferred way to do this?  A header line (which may be
truncated by some MTAs), a unique envelope sender (which requires some
support from the *LOCAL* MTA, and qmail and sendmail do it differently)?

Sean
-- 
 Her eyes were like two brown circles with big black dots in the center.
Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com>
URL: <http://www.tummy.com/xvscan> HP-UX/Linux/FreeBSD/BSDOS scanning software.


From claw@kanga.nu  Tue Nov 30 22:26:43 1999
From: claw@kanga.nu (claw@kanga.nu)
Date: Tue, 30 Nov 1999 14:26:43 -0800
Subject: [Mailman-Developers] Missed Bounce Message
In-Reply-To: Message from jfesler@gigo.com
 of "Tue, 30 Nov 1999 13:29:57 PST." <Pine.BSF.4.10.9911301328400.36918-100000@heaven.gigo.com>
Message-ID: <E11svjP-00002i-00@koala.kanga.nu>

On Tue, 30 Nov 1999 13:29:57 -0800 (PST) 
jfesler  <jfesler@gigo.com> wrote:

> Note that some mail servers refuse to send the message body back
> (grrr).  

I've found that the ones that don't at least send the headers are
few and far between (tho they do exist).

> If you do it as the envelope you're guaranteed to be able to
> recognize it, whether or not the body bounces..

True.

> [I'm also highly in favor of the at-password-time bounce checking
> - keeps load light-ish for most list traffic, and just the
> occasional reminder/probe]

As I mentioned to Barry, I opted for once every N messages where N
was configurable on a per-list basis.  This allowed some lists to be 
set trigger happy, and others lackadasical -- as befitted their
character and daily traffic loads.

Hurm.

My headers were:

  X-SubscriberData: subscr_address on <listname> #<lists's_bounce_count>"

The algorithm was:

  There were three configurable values per list: How often to issue
bounce messages: Every N days or M messages, whichever came the
sooner (no mail days genereated no bounce test messages), and a
sensitivity value.

  A bounced message was worth Q points, where Q was determined as
follows:

  To be removed from the list a member had to accrue a sufficiently
high bounce score.  The more rapidly he bounced messages the more
rapidly his score grew.  Gaps in bounces (is some bounce some don't,
and the score grows more slowly.

  Loosely, a mamber had to bounce every bounce_message for
<sensitivity> days with the bounce messages making it back to the
list server within 24 hours to be unsubscribed.

  This was done by calculating a bounce_score as follows:

    If the bounce message has the same bounce_count as the last
bounce-sensitive message issued (plus or minus one), then
<sensitivity> is added to the score.

    If the bounc message is from an older bounce-test, then
<sensitivity> - <age> - 1 is added to the score.

    If the bounce message is older than <sensitivity> days, then the
score is set to zero.

-- 
J C Lawrence                                 Home: claw@kanga.nu
----------(*)                              Other: coder@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


From bwarsaw@cnri.reston.va.us (Barry A. Warsaw)  Tue Nov 30 23:25:45 1999
From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw)
Date: Tue, 30 Nov 1999 18:25:45 -0500 (EST)
Subject: [Mailman-Developers] NT Port
References: <001401bf3b19$0dd75420$3acbd9c2@peridot.optichrome.com>
Message-ID: <14404.23801.728773.883739@anthem.cnri.reston.va.us>

>>>>> "AE" == Adrian Eyre <a.eyre@optichrome.com> writes:

    AE> Is there, or is anyone working on an NT port of Mailman?
    AE> If not, I may start working on one myself.

No one that I know of.  There have been some ideas floated on this
list in the past (search the archives at
http://www.python.org/search).

Good luck!
-Barry