From jaraya at aranet.cl  Mon May  3 17:55:46 2004
From: jaraya at aranet.cl (Juan Pablo Araya)
Date: Mon May  3 16:55:36 2004
Subject: [Mailman-Developers] How mailman manages threads in posts?
Message-ID: <20040503215546.3422.qmail@ns1.aranet.cl>

Hi 

Can someone tell me please any url where I can see the headers and 
implementation for mailman, so it can manage threads in the list archives? 

I would like to integrate the list with a forum. 

Thanks and sorry for my poor english

From ptomblin at xcski.com  Mon May  3 22:13:06 2004
From: ptomblin at xcski.com (Paul Tomblin)
Date: Mon May  3 22:19:13 2004
Subject: [Mailman-Developers] Maybe you guys can help me
Message-ID: <20040504021306.GA22619@allhats.xcski.com>

I tried asking this on mailman-users, and got totally ignored both times I
asked.  Here is my problem:  One of my mailing list users has an ISP that
refuses email for hours at a time, and the ISP that they get their email
through, panix.com, sends a warning if it's undelivered for four hours.
Problem is, mailman treats that warning as an error, and if it happens for
a few days in a row (even if the problem corrects itself for part of the
day and delivers the mail), it bounces her off my mailing lists.

The problem is that I don't know Python.  As far as I can tell, the fix to
ignore these warnings should go in Mailman/Bouncers/Postfix.py, but that's
all I can figure out.  Can somebody help me?

Here is a sanitized version of the bounce:

----- Forwarded message from mailman@xcski.com -----

Subject: Bounce action notification
From: mailman@xcski.com
To: XXXXXXX-owner@xcski.com
Date: Sat, 17 Apr 2004 16:36:23 -0400
X-Spam-Status: No, hits=-4.5 required=6.0 tests=AWL,BAYES_00,NO_REAL_NAME 
	autolearn=no version=2.63

This is a Mailman mailing list bounce action notice:

    List:       XXXXXXX
    Member:     XXXXXXX@echonyc.com
    Action:     Subscription disabled.
    Reason:     Excessive or fatal bounces.
    


The triggering bounce notice is attached below.

Questions? Contact the Mailman site administrator at
mailman@xcski.com.

Date: Sat, 17 Apr 2004 16:36:49 -0400 (EDT)
From: MAILER-DAEMON@panix.com (Mail Delivery System)
Subject: Delayed Mail (still being retried)
To: XXXXXXX-bounces@xcski.com

Content-Description: Notification
This is the Postfix program at host l2mail1.panix.com.

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

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

For further assistance, please send mail to <postmaster>

			The Postfix program

<XXXXXXX@echonyc.com>: connect to echonyc.com[198.67.15.2]: Connection refused

Content-Description: Delivery error report
Reporting-MTA: dns; l2mail1.panix.com
Arrival-Date: Sat, 17 Apr 2004 10:05:49 -0400 (EDT)

Final-Recipient: rfc822; XXXXXXX@echonyc.com
Action: delayed
Status: 4.0.0
Diagnostic-Code: X-Postfix; connect to echonyc.com[198.67.15.2]: Connection
    refused
Will-Retry-Until: Thu, 22 Apr 2004 10:05:49 -0400 (EDT)

[snip]
-- 
Paul Tomblin <ptomblin@xcski.com> http://xcski.com/blogs/pt/
I think I'd like to see a Simpsons episode starting up with Bart Simpson
writing 'I will not attempt to undermine the Usenet Cabal'.
              -- J. D. Falk

From chuqui at plaidworks.com  Tue May  4 00:43:53 2004
From: chuqui at plaidworks.com (Chuq Von Rospach)
Date: Tue May  4 00:45:11 2004
Subject: [Mailman-Developers] CVS timing out?
Message-ID: <A57259DA-9D85-11D8-BA48-0003934516A8@plaidworks.com>

went to update my site from CVS, and Im' getting timeouts from 
soureforge. anyone else having this problem, or is it just me (again?)


From somuchfun at atlantismail.com  Tue May  4 04:01:40 2004
From: somuchfun at atlantismail.com (Somuchfun)
Date: Tue May  4 04:01:58 2004
Subject: [Mailman-Developers] New feature request
Message-ID: <E1BKusE-0004w8-M5@mail.python.org>

Is it possible to have a new feature in the new version of mailman where a
site administrator can limit each list individually by how many members and
how much traffic it can have and also set a default for these values in
mm_cfg.py?
Also, it would be great to sort the member list by domain and by status
(active, suspended etc.) and get a good overview in numbers.
One other thing I have been missing is a clean up function where mailman
goes through the whole list and updates the members according current
settings.
For example:
Let's say the old settings were that a member had to bounce 20 times, then
be notified 4 times, each 7 days apart to be unsubscribed.
So let's assume there are 1,000 members in the list with the suspend status
who have been notified once already. Now the admin decides to change the
settings and have everyone only be notified once. A list update function
would then unsubscribe these 1,000 members because their status matches the
new settings.

Thanks for listening to the user community for improvements (are you
listening to us?)


From Nigel.Metheringham at dev.InTechnology.co.uk  Tue May  4 05:06:51 2004
From: Nigel.Metheringham at dev.InTechnology.co.uk (Nigel Metheringham)
Date: Tue May  4 05:07:02 2004
Subject: [Mailman-Developers] Maybe you guys can help me
In-Reply-To: <20040504021306.GA22619@allhats.xcski.com>
References: <20040504021306.GA22619@allhats.xcski.com>
Message-ID: <1083661610.8201.12.camel@angua.localnet>

On Tue, 2004-05-04 at 03:13, Paul Tomblin wrote:
> I tried asking this on mailman-users, and got totally ignored both times I
> asked.  Here is my problem:  One of my mailing list users has an ISP that
> refuses email for hours at a time, and the ISP that they get their email
> through, panix.com, sends a warning if it's undelivered for four hours.

They should not do this if the mail is marked as "low priority" - ie
Precedence set to values like "list" or "junk".  It could be worth
talking to panix about this.

My approach to such a problem would be either:-
      * My normal bloody mindedness - ie let the user's subscription
        die.
      * Filter the delay warnings before they hit mailman by using an
        MTA filter of some form.

	Nigel.

-- 
[ Nigel Metheringham           Nigel.Metheringham@InTechnology.co.uk ]
[ - Comments in this message are my own and not ITO opinion/policy - ]


From brad.knowles at skynet.be  Tue May  4 06:56:39 2004
From: brad.knowles at skynet.be (Brad Knowles)
Date: Tue May  4 07:00:04 2004
Subject: [Mailman-Developers] Maybe you guys can help me
In-Reply-To: <1083661610.8201.12.camel@angua.localnet>
References: <20040504021306.GA22619@allhats.xcski.com>
	<1083661610.8201.12.camel@angua.localnet>
Message-ID: <p0600202dbcbd261a1606@[10.0.1.2]>

At 10:06 AM +0100 2004/05/04, Nigel Metheringham wrote:

>  They should not do this if the mail is marked as "low priority" - ie
>  Precedence set to values like "list" or "junk".  It could be worth
>  talking to panix about this.

	I believe that I had seen and responded to his previous posting 
on mailman-users.  IIRC, Panix isn't about to change how they do 
anything.  Nor is the recipient ISP.  And the user refuses to move to 
a different ISP.

>        * Filter the delay warnings before they hit mailman by using an
>          MTA filter of some form.

	IIRC, Paul is using an ISP where he has no control over the MTA, 
and he's not about to change ISPs to a place where he might have more 
control over this.


	Having eliminated virtually every reasonable alternative, he 
either has to hack the Python code to avoid treating a warning as an 
error, or the user drops off the mailing list.  I see no other 
options.

	I seem to recall that I have previously said more or less the 
same thing to him.

-- 
Brad Knowles, <brad.knowles@skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

   SAGE member since 1995.  See <http://www.sage.org/> for more info.

From ptomblin at xcski.com  Tue May  4 07:03:26 2004
From: ptomblin at xcski.com (Paul Tomblin)
Date: Tue May  4 07:09:42 2004
Subject: [Mailman-Developers] Maybe you guys can help me
In-Reply-To: <p0600202dbcbd261a1606@[10.0.1.2]>
References: <20040504021306.GA22619@allhats.xcski.com>
	<1083661610.8201.12.camel@angua.localnet>
	<p0600202dbcbd261a1606@[10.0.1.2]>
Message-ID: <20040504110326.GB4994@allhats.xcski.com>

Quoting Brad Knowles (brad.knowles@skynet.be):
> At 10:06 AM +0100 2004/05/04, Nigel Metheringham wrote:
> > They should not do this if the mail is marked as "low priority" - ie
> > Precedence set to values like "list" or "junk".  It could be worth
> > talking to panix about this.
> 
> 	I believe that I had seen and responded to his previous posting 
> on mailman-users.  IIRC, Panix isn't about to change how they do 

Sorry, I don't believe I saw any responses to my question on mailman-users.

> >       * Filter the delay warnings before they hit mailman by using an
> >         MTA filter of some form.
> 
> 	IIRC, Paul is using an ISP where he has no control over the MTA, 
> and he's not about to change ISPs to a place where he might have more 
> control over this.

I do have some control over the MTA.  But it does seem a little ridiculous
to filter out warnings (but not errors) just because mailman insists on
treating warnings as errors.


-- 
Paul Tomblin <ptomblin@xcski.com> http://xcski.com/blogs/pt/
I'm just waiting for the day that someone decides that "ignorant moron" is
an ethnic group, and thus cannot be discriminated against.
              -- Christian Wagner

From Nigel.Metheringham at dev.InTechnology.co.uk  Tue May  4 07:20:46 2004
From: Nigel.Metheringham at dev.InTechnology.co.uk (Nigel Metheringham)
Date: Tue May  4 07:20:50 2004
Subject: [Mailman-Developers] Maybe you guys can help me
In-Reply-To: <20040504110326.GB4994@allhats.xcski.com>
References: <20040504021306.GA22619@allhats.xcski.com>
	<1083661610.8201.12.camel@angua.localnet>
	<p0600202dbcbd261a1606@[10.0.1.2]>
	<20040504110326.GB4994@allhats.xcski.com>
Message-ID: <1083669646.8201.24.camel@angua.localnet>

On Tue, 2004-05-04 at 12:03, Paul Tomblin wrote:
> I do have some control over the MTA.  But it does seem a little ridiculous
> to filter out warnings (but not errors) just because mailman insists on
> treating warnings as errors.

The ISP is sending bounces.  The fact that the text in the message says
these are warning messages rather than bounces does not change the fact
that the messages are bounces.

Mailman cannot parse every form of error message - in that direction
lies madness.  Does it need to be polyglot as well?

BTW one of the reasons I am moving to VERP handling of mailman mail is
so that I can then easily treat all these oddities that are currently
missed (due to crap internal message structure so that the end point
address cannot be derived) such as delay warning messages, TMDA or other
challenge response messages and similar crap.  They will all be treated
as straight bounces - send more than a couple and you get a free
invitation off the list.

	Nigel.

-- 
[ Nigel Metheringham           Nigel.Metheringham@InTechnology.co.uk ]
[ - Comments in this message are my own and not ITO opinion/policy - ]


From ptomblin at xcski.com  Tue May  4 07:33:17 2004
From: ptomblin at xcski.com (Paul Tomblin)
Date: Tue May  4 07:39:31 2004
Subject: [Mailman-Developers] Maybe you guys can help me
In-Reply-To: <1083669646.8201.24.camel@angua.localnet>
References: <20040504021306.GA22619@allhats.xcski.com>
	<1083661610.8201.12.camel@angua.localnet>
	<p0600202dbcbd261a1606@[10.0.1.2]>
	<20040504110326.GB4994@allhats.xcski.com>
	<1083669646.8201.24.camel@angua.localnet>
Message-ID: <20040504113317.GE4994@allhats.xcski.com>

Quoting Nigel Metheringham (Nigel.Metheringham@dev.InTechnology.co.uk):
> On Tue, 2004-05-04 at 12:03, Paul Tomblin wrote:
> > I do have some control over the MTA.  But it does seem a little ridiculous
> > to filter out warnings (but not errors) just because mailman insists on
> > treating warnings as errors.
> 
> The ISP is sending bounces.  The fact that the text in the message says
> these are warning messages rather than bounces does not change the fact
> that the messages are bounces.

No, it's sending warnings that are being incorrectly interpreted as
bounces.  The fact that the warning has one line that matches the niave
bounce parsing, but others that don't, shows that the bounce parsing is
broken.

sendmail has had that "4 hours undeliverable" warning since the days when
I was delivering email via uucp over a 2400bps modem.  It's not like this
is something that just crept up on people.

-- 
Paul Tomblin <ptomblin@xcski.com> http://xcski.com/blogs/pt/
Flying is not dangerous; crashing is dangerous.

From ptomblin at xcski.com  Tue May  4 07:45:14 2004
From: ptomblin at xcski.com (Paul Tomblin)
Date: Tue May  4 07:51:27 2004
Subject: [Mailman-Developers] Maybe you guys can help me
In-Reply-To: <1083669646.8201.24.camel@angua.localnet>
References: <20040504021306.GA22619@allhats.xcski.com>
	<1083661610.8201.12.camel@angua.localnet>
	<p0600202dbcbd261a1606@[10.0.1.2]>
	<20040504110326.GB4994@allhats.xcski.com>
	<1083669646.8201.24.camel@angua.localnet>
Message-ID: <20040504114514.GF4994@allhats.xcski.com>

Quoting Nigel Metheringham (Nigel.Metheringham@dev.InTechnology.co.uk):
> Mailman cannot parse every form of error message - in that direction
> lies madness.  Does it need to be polyglot as well?

By the way, I notice that Mailman/Bouncers/SimpleWarning seems to be where
the standard Sendmail 4 hour warning is handled, but unless I'm reading it
wrong (and that's possible, since I don't know Python) it appears to
handle that as a bounce, not a warning, in spite of the presence of a
provision in Bounces/BouncerAPI.py to swallow warnings.

-- 
Paul Tomblin <ptomblin@xcski.com> http://xcski.com/blogs/pt/
I have a longstanding agreement with tequila:
I won't drink it, and it won't make me sick.
              -- Brian Kantor

From jelly+mailman-dev at mail.iskon.hr  Mon May  3 20:15:12 2004
From: jelly+mailman-dev at mail.iskon.hr (Zoran Dzelajlija)
Date: Tue May  4 09:22:13 2004
Subject: [Mailman-Developers] Re: True Virtual Hosting With Mailman Hack
References: <20040428164653.GA83269@shall.anarcat.ath.cx>
Message-ID: <20040504001512.5C75.4.NOFFLE@islands.iskon.hr>

The Anarcat <anarcat@anarcat.ath.cx> wrote:
> [sourceforge seems to be down, so I post this here]

> Hi there,

> We developped a reliable solution for running lists with the same name
> on different domains on the same Mailman installation.

> I implemented that on top of the Mailman 2.1.1-5.1 Debian stable
> package.  All that is needed is to patch 2 files (bin/newlist,
> Mailman/MailList.py) in the mailman install, and here is the patch:

> http://bugs.koumbit.net/file_download.php?file_id=3&type=bug

> There's only one caveat right now: Mailman/Cgi/create.py might need to
> get patched too, but I haven't got around looking at it yet, and it
> "just works", for now.

I've implemented a patch like this some time ago, and it has somewhat grown
during time due to various bugs we found out.  I didn't check your patch,
since I'm writing this offline, but here are some gotchas that weren't so
obvious for us:

_setValue in Mailman/Gui/General.py has to be patched, or your list
admins won't be able to make real_name case changes.  This bug can also be
found in (some?) cPanel versions.

There's also some usage of internal_name in HasExplicitDest() in
MailList.py, which would make Mailman hold messages errorneously
under certain circumstances:

--------------
diff -Nru mailman-2.1.4/Mailman/MailList.py mailman-2.1.4.patched/Mailman/MailList.py
--- mailman-2.1.4/Mailman/MailList.py	2003-12-01 01:54:16.000000000 +0100
+++ mailman-2.1.4.patched/Mailman/MailList.py	2004-01-09 15:22:16.463664000 +0100
@@ -1243,7 +1243,7 @@
         to or cc addrs."""
         # BAW: fall back to Utils.ParseAddr if the first test fails.
         # this is the list's full address
-        listfullname = '%s@%s' % (self.internal_name(), self.host_name)
+        listfullname = self.getListAddress()
         recips = []
         # check all recipient addresses against the list's explicit addresses,
         # specifically To: Cc: and Resent-to:
@@ -1259,7 +1259,7 @@
             addr = addr.lower()
             localpart = addr.split('@')[0]
             if (# TBD: backwards compatibility: deprecated
-                    localpart == self.internal_name() or
+                    localpart == self.real_name.lower() or
                     # exact match against the complete list address
                     addr == listfullname):
                 return 1
--------------

> All it does is to add the domain to the internal_name() of a list. The
> real_name is kept as is, and the getListAddress() does the Right Thing.

Hope you did not forget to use .lower() on self.real_name in
getListAddress(), like we did.  ;-)  There, so you now know all the
mistakes we made (and found out about).

Regards,
Zoran


From claw at kanga.nu  Tue May  4 10:25:51 2004
From: claw at kanga.nu (J C Lawrence)
Date: Tue May  4 10:25:55 2004
Subject: [Mailman-Developers] Maybe you guys can help me 
In-Reply-To: Message from Paul Tomblin <ptomblin@xcski.com> of "Tue,
	04 May 2004 07:03:26 EDT." <20040504110326.GB4994@allhats.xcski.com> 
References: <20040504021306.GA22619@allhats.xcski.com>
	<1083661610.8201.12.camel@angua.localnet>
	<p0600202dbcbd261a1606@[10.0.1.2]>
	<20040504110326.GB4994@allhats.xcski.com> 
Message-ID: <28242.1083680751@kanga.nu>

On Tue, 4 May 2004 07:03:26 -0400 
Paul Tomblin <ptomblin@xcski.com> wrote:

> I do have some control over the MTA.  But it does seem a little
> ridiculous to filter out warnings (but not errors) just because
> mailman insists on treating warnings as errors.

Reliably distinguishing is non-trivial.

-- 
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
claw@kanga.nu               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

From brad.knowles at skynet.be  Tue May  4 11:28:34 2004
From: brad.knowles at skynet.be (Brad Knowles)
Date: Tue May  4 11:36:35 2004
Subject: [Mailman-Developers] Maybe you guys can help me
In-Reply-To: <1083669646.8201.24.camel@angua.localnet>
References: <20040504021306.GA22619@allhats.xcski.com>
	<1083661610.8201.12.camel@angua.localnet>
	<p0600202dbcbd261a1606@[10.0.1.2]>
	<20040504110326.GB4994@allhats.xcski.com>
	<1083669646.8201.24.camel@angua.localnet>
Message-ID: <p0600202ebcbd6551e6ef@[10.0.1.2]>

At 12:20 PM +0100 2004/05/04, Nigel Metheringham wrote:

>  The ISP is sending bounces.  The fact that the text in the message says
>  these are warning messages rather than bounces does not change the fact
>  that the messages are bounces.

	Technically, they are not "bounces".  They are Delivery Status 
Notifications.

>  Mailman cannot parse every form of error message - in that direction
>  lies madness.  Does it need to be polyglot as well?

	No, but we could make an attempt to better handle the standard 
format messages, as described by the RFCs.

-- 
Brad Knowles, <brad.knowles@skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

   SAGE member since 1995.  See <http://www.sage.org/> for more info.

From carson at taltos.org  Tue May  4 11:40:49 2004
From: carson at taltos.org (Carson Gaspar)
Date: Tue May  4 11:41:06 2004
Subject: [Mailman-Developers] Maybe you guys can help me 
In-Reply-To: <28242.1083680751@kanga.nu>
References: <20040504021306.GA22619@allhats.xcski.com>
	<1083661610.8201.12.camel@angua.localnet>	<p0600202dbcbd261a1606@[10.0.1.2]>
	<20040504110326.GB4994@allhats.xcski.com> <28242.1083680751@kanga.nu>
Message-ID: <E8DAE174C87231754F5BA626@[192.168.20.2]>



--On Tuesday, May 04, 2004 10:25 AM -0400 J C Lawrence <claw@kanga.nu> 
wrote:

> On Tue, 4 May 2004 07:03:26 -0400
> Paul Tomblin <ptomblin@xcski.com> wrote:
>
>> I do have some control over the MTA.  But it does seem a little
>> ridiculous to filter out warnings (but not errors) just because
>> mailman insists on treating warnings as errors.
>
> Reliably distinguishing is non-trivial.

Incorrect. Parsing RFC-standard DSNs is trivial. I wrote the code to do it 
back in the old days when I ran the firewalls mailing list.

-- 
Carson




From bob at nleaudio.com  Tue May  4 11:58:40 2004
From: bob at nleaudio.com (Bob Puff@NLE)
Date: Tue May  4 11:57:47 2004
Subject: [Mailman-Developers] Maybe you guys can help me
In-Reply-To: <E8DAE174C87231754F5BA626@[192.168.20.2]>
References: <20040504021306.GA22619@allhats.xcski.com>	<1083661610.8201.12.camel@angua.localnet>	<p0600202dbcbd261a1606@[10.0.1.2]>	<20040504110326.GB4994@allhats.xcski.com>
	<28242.1083680751@kanga.nu>
	<E8DAE174C87231754F5BA626@[192.168.20.2]>
Message-ID: <4097BDB0.20906@nleaudio.com>

And how many "RFC-Standard" DSNs are out there, compared to non-standard?  He's right, it is not the 
least bit trivial.

Bob

Carson Gaspar wrote:
> 
> 
> --On Tuesday, May 04, 2004 10:25 AM -0400 J C Lawrence <claw@kanga.nu> 
> wrote:
> 
>> On Tue, 4 May 2004 07:03:26 -0400
>> Paul Tomblin <ptomblin@xcski.com> wrote:
>>
>>> I do have some control over the MTA.  But it does seem a little
>>> ridiculous to filter out warnings (but not errors) just because
>>> mailman insists on treating warnings as errors.
>>
>>
>> Reliably distinguishing is non-trivial.
> 
> 
> Incorrect. Parsing RFC-standard DSNs is trivial. I wrote the code to do 
> it back in the old days when I ran the firewalls mailing list.
> 


From brad.knowles at skynet.be  Tue May  4 11:56:49 2004
From: brad.knowles at skynet.be (Brad Knowles)
Date: Tue May  4 11:57:49 2004
Subject: [Mailman-Developers] Maybe you guys can help me
In-Reply-To: <E8DAE174C87231754F5BA626@[192.168.20.2]>
References: <20040504021306.GA22619@allhats.xcski.com>
	<1083661610.8201.12.camel@angua.localnet>
	<p0600202dbcbd261a1606@[10.0.1.2]>
	<20040504110326.GB4994@allhats.xcski.com>
	<28242.1083680751@kanga.nu>
	<E8DAE174C87231754F5BA626@[192.168.20.2]>
Message-ID: <p06002033bcbd6d5aca0a@[10.0.1.2]>

At 11:40 AM -0400 2004/05/04, Carson Gaspar quoted JC Lawrence:

>>  Reliably distinguishing is non-trivial.
>
>  Incorrect. Parsing RFC-standard DSNs is trivial. I wrote the code to
>  do it back in the old days when I ran the firewalls mailing list.

	I think JC was talking about the broader subject, more than just 
the standard DSNs.

	I agree with you that we could do a better job of parsing and 
handling the standard DSNs, but I agree with JC that this is a very 
tough task to do beyond the standard DSNs.

-- 
Brad Knowles, <brad.knowles@skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

   SAGE member since 1995.  See <http://www.sage.org/> for more info.

From ptomblin at xcski.com  Tue May  4 12:08:06 2004
From: ptomblin at xcski.com (Paul Tomblin)
Date: Tue May  4 12:14:23 2004
Subject: [Mailman-Developers] Maybe you guys can help me
In-Reply-To: <4097BDB0.20906@nleaudio.com>
References: <20040504021306.GA22619@allhats.xcski.com>
	<1083661610.8201.12.camel@angua.localnet>
	<p0600202dbcbd261a1606@[10.0.1.2]>
	<20040504110326.GB4994@allhats.xcski.com>
	<28242.1083680751@kanga.nu>
	<E8DAE174C87231754F5BA626@[192.168.20.2]>
	<4097BDB0.20906@nleaudio.com>
Message-ID: <20040504160806.GA14259@allhats.xcski.com>

Quoting Bob Puff@NLE (bob@nleaudio.com):
> And how many "RFC-Standard" DSNs are out there, compared to non-standard?  
> He's right, it is not the least bit trivial.

The point is that Mailman already has code to parse dozens of different
bounce messages.  I don't see why everybody is getting so hinky about
adding one more.

-- 
Paul Tomblin <ptomblin@xcski.com> http://xcski.com/blogs/pt/
"The surreality of the universe tends towards a maximum"  -- Skud's Law
"Never formulate a law or axiom that you're not prepared to live with
the consequences of."  -- Skud's Meta-Law

From claw at kanga.nu  Tue May  4 12:40:27 2004
From: claw at kanga.nu (J C Lawrence)
Date: Tue May  4 12:40:32 2004
Subject: [Mailman-Developers] Maybe you guys can help me 
In-Reply-To: Message from Carson Gaspar <carson@taltos.org> of "Tue,
	04 May 2004 11:40:49 EDT." <E8DAE174C87231754F5BA626@[192.168.20.2]> 
References: <20040504021306.GA22619@allhats.xcski.com>
	<1083661610.8201.12.camel@angua.localnet>
	<p0600202dbcbd261a1606@[10.0.1.2]>
	<20040504110326.GB4994@allhats.xcski.com>
	<28242.1083680751@kanga.nu>
	<E8DAE174C87231754F5BA626@[192.168.20.2]> 
Message-ID: <7313.1083688827@kanga.nu>

On Tue, 04 May 2004 11:40:49 -0400 
Carson Gaspar <carson@taltos.org> wrote:
> --On Tuesday, May 04, 2004 10:25 AM -0400 J C Lawrence <claw@kanga.nu>
> wrote:

>> Reliably distinguishing is non-trivial.

> Incorrect. Parsing RFC-standard DSNs is trivial. I wrote the code to
> do it back in the old days when I ran the firewalls mailing list.

That's true only while you maintain the "RFC-standard DSNs" qualifier.
Very few of the DSNs my lists receive are RFC-conformant.

-- 
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
claw@kanga.nu               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

From carson at taltos.org  Tue May  4 12:46:42 2004
From: carson at taltos.org (Carson Gaspar)
Date: Tue May  4 12:46:47 2004
Subject: [Mailman-Developers] Maybe you guys can help me 
In-Reply-To: <7313.1083688827@kanga.nu>
References: <20040504021306.GA22619@allhats.xcski.com>
	<1083661610.8201.12.camel@angua.localnet>
	<p0600202dbcbd261a1606@[10.0.1.2]>
	<20040504110326.GB4994@allhats.xcski.com> <28242.1083680751@kanga.nu> 
	<E8DAE174C87231754F5BA626@[192.168.20.2]>  <7313.1083688827@kanga.nu>
Message-ID: <613930000.1083689202@taltos.ny.ficc.gs.com>

[ I am on the list, guys - no need to CC me... ]

--On Tuesday, May 04, 2004 12:40:27 -0400 J C Lawrence <claw@kanga.nu> 
wrote:

> That's true only while you maintain the "RFC-standard DSNs" qualifier.
> Very few of the DSNs my lists receive are RFC-conformant.

So if they aren't compliant, we treat them as the gobbledygook they are. No 
reason not to handle correct DSNs from sendmail, postfix, et al. This is a 
textbook case of "solving the universe's problems is too hard, so I won't 
take out the trash". And yes, I _did_ write the code to handle _exactly_ 
this case in the mailman 1.x days (along with a bunch of other bounce 
handlers). It's a shame it got lost.

-- 
Carson


From bob at nleaudio.com  Tue May  4 13:38:19 2004
From: bob at nleaudio.com (Bob Puff@NLE)
Date: Tue May  4 13:38:23 2004
Subject: [Mailman-Developers] Maybe you guys can help me
In-Reply-To: <20040504160806.GA14259@allhats.xcski.com>
References: <20040504021306.GA22619@allhats.xcski.com>
	<1083661610.8201.12.camel@angua.localnet>
	<p0600202dbcbd261a1606@[10.0.1.2]>
	<20040504110326.GB4994@allhats.xcski.com>
	<28242.1083680751@kanga.nu>
	<E8DAE174C87231754F5BA626@[192.168.20.2]>
	<4097BDB0.20906@nleaudio.com>
	<20040504160806.GA14259@allhats.xcski.com>
Message-ID: <20040504173819.M98054@nleaudio.com>

...Because it's not just one more.  I re-wrote the bounce handling for my own 
2.0.x boxes, and spent endless hours trying to keep up with all the 
difference bounce messages that weren't caught.  I ended up giving up.  If 
their ISP is broken enough that it generates bounce messages, then their 
unsubscription problem isn't mine.

What will happen is that your test for "soft" bounces is going to register 
some "hard" bounces incorrectly, and then its downhill from there.

I haven't looked at the latest handlers, but my code says something like: if 
the person hasn't bounced in two days (of messages each day), then reset 
their counter.  So if they constantly generate these messages, there is a 
very real problem with that ISP.

Bob


---------- Original Message -----------
From: Paul Tomblin <ptomblin@xcski.com>
To: mailman-developers@python.org
Sent: Tue, 4 May 2004 12:08:06 -0400
Subject: Re: [Mailman-Developers] Maybe you guys can help me

> Quoting Bob Puff@NLE (bob@nleaudio.com):
> > And how many "RFC-Standard" DSNs are out there, compared to non-
standard?  
> > He's right, it is not the least bit trivial.
> 
> The point is that Mailman already has code to parse dozens of different
> bounce messages.  I don't see why everybody is getting so hinky about
> adding one more.
> 
> -- 
> Paul Tomblin <ptomblin@xcski.com> http://xcski.com/blogs/pt/
> "The surreality of the universe tends towards a maximum"  -- Skud's Law
> "Never formulate a law or axiom that you're not prepared to live with
> the consequences of."  -- Skud's Meta-Law
> 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/bob%
40nleaudio.com
------- End of Original Message -------


From chuqui at plaidworks.com  Tue May  4 13:48:16 2004
From: chuqui at plaidworks.com (Chuq Von Rospach)
Date: Tue May  4 13:48:25 2004
Subject: [Mailman-Developers] Maybe you guys can help me
In-Reply-To: <20040504173819.M98054@nleaudio.com>
References: <20040504021306.GA22619@allhats.xcski.com>
	<1083661610.8201.12.camel@angua.localnet>
	<p0600202dbcbd261a1606@[10.0.1.2]>
	<20040504110326.GB4994@allhats.xcski.com>
	<28242.1083680751@kanga.nu>
	<E8DAE174C87231754F5BA626@[192.168.20.2]>
	<4097BDB0.20906@nleaudio.com>
	<20040504160806.GA14259@allhats.xcski.com>
	<20040504173819.M98054@nleaudio.com>
Message-ID: <391C06A4-9DF3-11D8-A2E1-0003934516A8@plaidworks.com>


On May 4, 2004, at 10:38 AM, Bob Puff@NLE wrote:

>  If
> their ISP is broken enough that it generates bounce messages, then 
> their
> unsubscription problem isn't mine.

it's not always easy to convince their users of that.

Which ties back to the original problem. Those "warning" 
not-really-bounces are anachronisms of the days when all this was tied 
to UUCP. Basically, they should die. the only way you convince sites to 
fix THEIR problems is to convince their users to whine enough to make 
them care. You can't do that if you "fix the problem in Mailman" by 
making it go away. Think about what behavior your reinforcing when you 
make a change, and whether that's the behavior you want to encourage.

the same thing is happening with anti-spam and anti-virus tools, who 
seem to think they "fix" the problem by bouncing crap into everyone 
else's mailboxes. my current thought on that is:

http://www.plaidworks.com/chuqui/blog/001447.html

which basically boils down to "if it looks like a bounce and quacks 
like a bounce and swears like a bounce, then dammit, it's a bounce".

And the only way to make THEM fix their damned systems to not bounce 
stuff that shouldn't bounce is to make it a visible problem to them. 
You don't do that by "fixing" mailman. Unfortunately, it'll cause some 
pain for users, but my feeling is, if their stuff is bouncing and they 
odn't realize it, that's a bigger problem they SHOULD be warned about,a 
nyway.

so my policy is now simple: if you bounce it back, I'll treat it like a 
bounce. If it has the word "spam" in it anywhere, it'll be treated like 
a complaint against my server, and suffer immediate unsubscription. if 
that's not what you (the user/subscriber) wanted, then complain to YOUR 
admins, since tehy're the ones that did it. I'm just not trying to 
second-guess them any more and figure out which bounces are real, and 
which ones aren't. if they send it, they must mean it.

and I suggest Mailman as a package take that approach, if we want to 
have any hope of convincing admins to get their bleeding act together. 
Because if we wallpaper over it in the bounce processor, we give them 
no motivation to fix it, do we? and what really ought to be fixed?

Tweaking this stuff in mailman is dealing with a symptom, but not 
encouraing the real problem to be looked at.


From ptomblin at xcski.com  Tue May  4 13:42:20 2004
From: ptomblin at xcski.com (Paul Tomblin)
Date: Tue May  4 13:48:37 2004
Subject: [Mailman-Developers] Maybe you guys can help me
In-Reply-To: <20040504173819.M98054@nleaudio.com>
References: <20040504021306.GA22619@allhats.xcski.com>
	<1083661610.8201.12.camel@angua.localnet>
	<p0600202dbcbd261a1606@[10.0.1.2]>
	<20040504110326.GB4994@allhats.xcski.com>
	<28242.1083680751@kanga.nu>
	<E8DAE174C87231754F5BA626@[192.168.20.2]>
	<4097BDB0.20906@nleaudio.com>
	<20040504160806.GA14259@allhats.xcski.com>
	<20040504173819.M98054@nleaudio.com>
Message-ID: <20040504174220.GB17065@allhats.xcski.com>

Quoting Bob Puff@NLE (bob@nleaudio.com):
> I haven't looked at the latest handlers, but my code says something like: if 
> the person hasn't bounced in two days (of messages each day), then reset 
> their counter.  So if they constantly generate these messages, there is a 
> very real problem with that ISP.

The problem seems to be that they hold up email for 4 or 5 hours a day for
several days in a row.  Hundreds of messages a day get through correctly,
but if one of them is held up for four hours each day for the designated
number of days, she gets bounced off.

Yeah, it's a problem with her ISP.  That's not my problem.  My problem is
that Mailman has dozens if not hundreds of individual specialized bounce
handlers, I asked for help with modifying one of them, and everybody
treats me like I'm asking for how to draw a moustache on the Mona Lisa.

The code is already a nest of special cases.  It won't hurt the pristine
nature of the perfect code to add a small check and NOT mishandle one
thing that is erroneously treated as a bounce.  Especially since it
appears that somebody already added something to the API to allow warnings
to be silently ignored.

I figured somebody who knew the code could tell me what and where to
change it in less time than it would take to argue about it, but I guess I
was wrong.  Sorry I pissed on your wheaties, guys.  I guess I'll buy a
Python book and do it myself.

-- 
Paul Tomblin <ptomblin@xcski.com> http://xcski.com/blogs/pt/
 SCSI is *NOT* magic. There are *fundamental technical reasons* why it is
 necessary to sacrifice a young goat to your SCSI chain now and then.

From barry at python.org  Tue May  4 14:01:09 2004
From: barry at python.org (Barry Warsaw)
Date: Tue May  4 14:01:16 2004
Subject: [Mailman-Developers] Maybe you guys can help me
In-Reply-To: <1083661610.8201.12.camel@angua.localnet>
References: <20040504021306.GA22619@allhats.xcski.com>
	<1083661610.8201.12.camel@angua.localnet>
Message-ID: <1083693669.4103.202.camel@anthem.wooz.org>

On Tue, 2004-05-04 at 05:06, Nigel Metheringham wrote:

> They should not do this if the mail is marked as "low priority" - ie
> Precedence set to values like "list" or "junk"

Absolutely right.  And you can hack Mailman all you like to try to
recognize these warnings, but in the long run I don't think it will help
those users very much.  I predict that they'll get bounced from lists
handled by other MLM's just as handily.  Or they will piss off people
who send them legit email.

You could of course turn off all bounce processing <wink> for your lists
if you wanted to coddle your users.

Or you could wait for Mailman 2.1.5, which will send a probe before
disabling them, once their bounce score reaches the threshold.  The
probe will verp in a unique token and if their mailer sends a warning
back for that, well they're out of luck.

The bottom line is that MTA warnings for precedence bulk has been a
well-known misconfiguration for a long time.

-Barry



From barry at python.org  Tue May  4 14:04:43 2004
From: barry at python.org (Barry Warsaw)
Date: Tue May  4 14:04:50 2004
Subject: [Mailman-Developers] Maybe you guys can help me
In-Reply-To: <p0600202ebcbd6551e6ef@[10.0.1.2]>
References: <20040504021306.GA22619@allhats.xcski.com>
	<1083661610.8201.12.camel@angua.localnet>
	<p0600202dbcbd261a1606@[10.0.1.2]>
	<20040504110326.GB4994@allhats.xcski.com>
	<1083669646.8201.24.camel@angua.localnet>
	<p0600202ebcbd6551e6ef@[10.0.1.2]>
Message-ID: <1083693883.4103.205.camel@anthem.wooz.org>

On Tue, 2004-05-04 at 11:28, Brad Knowles wrote:

> >  Mailman cannot parse every form of error message - in that direction
> >  lies madness.  Does it need to be polyglot as well?
> 
> 	No, but we could make an attempt to better handle the standard 
> format messages, as described by the RFCs.

If the DSN conforms to RFC 3464, Mailman should not register a bounce
for Action: delayed.  If it does, then it's a bug.

See Mailman/Bouncers/DSN.py

-Barry



From barry at python.org  Tue May  4 14:07:49 2004
From: barry at python.org (Barry Warsaw)
Date: Tue May  4 14:07:56 2004
Subject: [Mailman-Developers] Maybe you guys can help me
In-Reply-To: <p06002033bcbd6d5aca0a@[10.0.1.2]>
References: <20040504021306.GA22619@allhats.xcski.com>
	<1083661610.8201.12.camel@angua.localnet>
	<p0600202dbcbd261a1606@[10.0.1.2]>
	<20040504110326.GB4994@allhats.xcski.com> <28242.1083680751@kanga.nu>
	<E8DAE174C87231754F5BA626@[192.168.20.2]>
	<p06002033bcbd6d5aca0a@[10.0.1.2]>
Message-ID: <1083694069.4103.211.camel@anthem.wooz.org>

On Tue, 2004-05-04 at 11:56, Brad Knowles wrote:

> 	I think JC was talking about the broader subject, more than just 
> the standard DSNs.
> 
> 	I agree with you that we could do a better job of parsing and 
> handling the standard DSNs, but I agree with JC that this is a very 
> tough task to do beyond the standard DSNs.

Mailman /should/ be able to parse RFC 3464 DSNs accurately, at the very
least to tell whether the notification indicates a permanent failure or
not.  If it's not working right, it's a bug.

All the 'magical' bounce detection stuff in the other Mailman/Bouncers
modules is a losing battle, and I don't have much motivation to keep up
with the arms race.  DSN and VERP should be all we need.

-Barry



From barry at python.org  Tue May  4 14:13:03 2004
From: barry at python.org (Barry Warsaw)
Date: Tue May  4 14:13:14 2004
Subject: [Mailman-Developers] Maybe you guys can help me
In-Reply-To: <391C06A4-9DF3-11D8-A2E1-0003934516A8@plaidworks.com>
References: <20040504021306.GA22619@allhats.xcski.com>
	<1083661610.8201.12.camel@angua.localnet>
	<p0600202dbcbd261a1606@[10.0.1.2]>
	<20040504110326.GB4994@allhats.xcski.com> <28242.1083680751@kanga.nu>
	<E8DAE174C87231754F5BA626@[192.168.20.2]> <4097BDB0.20906@nleaudio.com>
	<20040504160806.GA14259@allhats.xcski.com>
	<20040504173819.M98054@nleaudio.com>
	<391C06A4-9DF3-11D8-A2E1-0003934516A8@plaidworks.com>
Message-ID: <1083694383.4103.215.camel@anthem.wooz.org>

On Tue, 2004-05-04 at 13:48, Chuq Von Rospach wrote:

> And the only way to make THEM fix their damned systems to not bounce 
> stuff that shouldn't bounce is to make it a visible problem to them. 
> You don't do that by "fixing" mailman. Unfortunately, it'll cause some 
> pain for users, but my feeling is, if their stuff is bouncing and they 
> odn't realize it, that's a bigger problem they SHOULD be warned about,a 
> nyway.

BTW, with MM2.1.5, users will have more knowledge at their disposal to
complain to their ISPs because the probe message will contain the last
bounce we received for them.  So if it's a warning that's causing them
to get disabled (or to get the probe), they'll know it.

-Barry



From barry at python.org  Tue May  4 14:17:14 2004
From: barry at python.org (Barry Warsaw)
Date: Tue May  4 14:17:24 2004
Subject: [Mailman-Developers] Maybe you guys can help me
In-Reply-To: <20040504174220.GB17065@allhats.xcski.com>
References: <20040504021306.GA22619@allhats.xcski.com>
	<1083661610.8201.12.camel@angua.localnet>
	<p0600202dbcbd261a1606@[10.0.1.2]>
	<20040504110326.GB4994@allhats.xcski.com> <28242.1083680751@kanga.nu>
	<E8DAE174C87231754F5BA626@[192.168.20.2]> <4097BDB0.20906@nleaudio.com>
	<20040504160806.GA14259@allhats.xcski.com>
	<20040504173819.M98054@nleaudio.com>
	<20040504174220.GB17065@allhats.xcski.com>
Message-ID: <1083694633.4103.222.camel@anthem.wooz.org>

On Tue, 2004-05-04 at 13:42, Paul Tomblin wrote:

> The code is already a nest of special cases.  It won't hurt the pristine
> nature of the perfect code to add a small check and NOT mishandle one
> thing that is erroneously treated as a bounce.  Especially since it
> appears that somebody already added something to the API to allow warnings
> to be silently ignored.

Actually, it may, so if you decide to code it up (and it /definitely/
ain't gonna happen if you don't), you need to be careful.  If your
change catches something or reports a false-positive or false-negative,
it could cause other bounce processors to miss the message.

I wish the bounce processors had a better test suite, but you can (and
should) add your additions to tests/test_bounces.py and make sure
everything there still passes.

-Barry



From claw at kanga.nu  Tue May  4 14:53:39 2004
From: claw at kanga.nu (J C Lawrence)
Date: Tue May  4 14:53:44 2004
Subject: [Mailman-Developers] Maybe you guys can help me 
In-Reply-To: Message from Chuq Von Rospach <chuqui@plaidworks.com> of "Tue,
	04 May 2004 10:48:16 PDT."
	<391C06A4-9DF3-11D8-A2E1-0003934516A8@plaidworks.com> 
References: <20040504021306.GA22619@allhats.xcski.com>
	<1083661610.8201.12.camel@angua.localnet>
	<p0600202dbcbd261a1606@[10.0.1.2]>
	<20040504110326.GB4994@allhats.xcski.com>
	<28242.1083680751@kanga.nu>
	<E8DAE174C87231754F5BA626@[192.168.20.2]>
	<4097BDB0.20906@nleaudio.com>
	<20040504160806.GA14259@allhats.xcski.com>
	<20040504173819.M98054@nleaudio.com>
	<391C06A4-9DF3-11D8-A2E1-0003934516A8@plaidworks.com> 
Message-ID: <19562.1083696819@kanga.nu>

On Tue, 4 May 2004 10:48:16 -0700 
Chuq Von Rospach <chuqui@plaidworks.com> wrote:
> On May 4, 2004, at 10:38 AM, Bob Puff@NLE wrote:

> Which ties back to the original problem. Those "warning"
> not-really-bounces are anachronisms of the days when all this was tied
> to UUCP. 

Good point.

> which basically boils down to "if it looks like a bounce and quacks
> like a bounce and swears like a bounce, then dammit, it's a bounce".

I'm generally of the mind that my responsibility as list admin is to
deliver an SMTP packet stream containing the mail to one of their MXes.
Once I've done that my job is done.  What they decide to do from there
is their problem, and if their choices annoy me it may reflect on my
willingness to keep trying to deliver messages to them.  TANSTAAFL.
Non-conformant bounces and DSNs are annoying choices, intentional or
otherwise.  At some point this fact needs to be faced.

> And the only way to make THEM fix their damned systems to not bounce
> stuff that shouldn't bounce is to make it a visible problem to
> them. You don't do that by "fixing" mailman. Unfortunately, it'll
> cause some pain for users, but my feeling is, if their stuff is
> bouncing and they odn't realize it, that's a bigger problem they
> SHOULD be warned about,a nyway.

cf Usenet death penalty.

> so my policy is now simple: if you bounce it back, I'll treat it like
> a bounce. If it has the word "spam" in it anywhere, it'll be treated
> like a complaint against my server, and suffer immediate
> unsubscription. 

I've a minor tendency to whack entire domains that abuse the abuse@
line.

> Tweaking this stuff in mailman is dealing with a symptom, but not
> encouraing the real problem to be looked at.

Quite.

-- 
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
claw@kanga.nu               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

From chuqui at plaidworks.com  Tue May  4 16:23:07 2004
From: chuqui at plaidworks.com (Chuq Von Rospach)
Date: Tue May  4 16:23:14 2004
Subject: [Mailman-Developers] Maybe you guys can help me
In-Reply-To: <20040504174220.GB17065@allhats.xcski.com>
References: <20040504021306.GA22619@allhats.xcski.com>
	<1083661610.8201.12.camel@angua.localnet>
	<p0600202dbcbd261a1606@[10.0.1.2]>
	<20040504110326.GB4994@allhats.xcski.com>
	<28242.1083680751@kanga.nu>
	<E8DAE174C87231754F5BA626@[192.168.20.2]>
	<4097BDB0.20906@nleaudio.com>
	<20040504160806.GA14259@allhats.xcski.com>
	<20040504173819.M98054@nleaudio.com>
	<20040504174220.GB17065@allhats.xcski.com>
Message-ID: <DAD807FC-9E08-11D8-A2E1-0003934516A8@plaidworks.com>


> handlers, I asked for help with modifying one of them, and everybody
> treats me like I'm asking for how to draw a moustache on the Mona Lisa.
>
> The code is already a nest of special cases.  It won't hurt the 
> pristine
> nature of the perfect code to add a small check and NOT mishandle one
> thing that is erroneously treated as a bounce.

but that ignores a core point.

"can do" is one thing. Can it be done? sure. But the real question is 
"should do", and it should be clear now that many of us feel it's the 
wrong thing to do on a philsophical level. Just because you CAN do 
something doesn't make it something you OUGHT to do, or the right 
thing.

>  I guess I'll buy a
> Python book and do it myself.
>

which is always an option, but it doesn't solve the problem. in fact, 
it encourages the wrong behavior to continue. your choosing quiet over 
justice (to misquote bill cosby) only makes it worse for everyone else, 
because it doesn't help the common good of fixing the baseline problem 
by encouraging the ISP to fix its stupid mailer.

And you're welcome to make that choice -- but don't get pissed at the 
project for not helping you do something the project sees as not an 
improvement or bad for the common good.



From darrell at grumblesmurf.net  Tue May  4 17:35:49 2004
From: darrell at grumblesmurf.net (Darrell Fuhriman)
Date: Tue May  4 17:35:55 2004
Subject: [Mailman-Developers] Maybe you guys can help me
In-Reply-To: <391C06A4-9DF3-11D8-A2E1-0003934516A8@plaidworks.com> (Chuq Von
	Rospach's message of "Tue, 4 May 2004 10:48:16 -0700")
References: <20040504021306.GA22619@allhats.xcski.com>
	<1083661610.8201.12.camel@angua.localnet>
	<p0600202dbcbd261a1606@[10.0.1.2]>
	<20040504110326.GB4994@allhats.xcski.com> <28242.1083680751@kanga.nu>
	<E8DAE174C87231754F5BA626@[192.168.20.2]>
	<4097BDB0.20906@nleaudio.com>
	<20040504160806.GA14259@allhats.xcski.com>
	<20040504173819.M98054@nleaudio.com>
	<391C06A4-9DF3-11D8-A2E1-0003934516A8@plaidworks.com>
Message-ID: <tsh3c6fdgei.fsf@pickwick.garnix.org>

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

> Which ties back to the original problem. Those "warning"
> not-really-bounces are anachronisms of the days when all this was tied
> to UUCP. Basically, they should die. the only way you convince sites

It doesn't really matter *why*, by god.  The fact is they are
here, they are in the RFCs and we should bloody well deal with
it.  The DSN RFC specifies that warnings exist, and we should be
treating them as warnings, not as errors.

If we don't want delay notifications, then why are we not
specifying "NOTIFY=FAILURE" when sending the message to the MTA?
(ESMTP "NOTIFY" commands are supposed to propagate down the line
whenever possible.)

RFC 3461, Page 7:

   "For compatibility with SMTP clients that do not use the
   NOTIFY facility, the absence of a NOTIFY parameter in a RCPT
   command may be interpreted as either NOTIFY=FAILURE or
   NOTIFY=FAILURE,DELAY."

Don't blame the MTAs for doing what is *defined* as correct and
acceptable.

(BTW, we should consider using ENVID [perhaps in addition to
VERP], if we want some help processing bounces.)

All this bitching and whining about not wanting to cope with the
errors/warnings we get back ("*wah* it's *hard*") is a little
ridiculous when we haven't even made a cursory effort to ask for
only the ones we care about.[1]

Darrell

[1] yes, not all MTAs will honor it.  so what?  If we're actually
making an effort then the "all bounces are fatal" contingent
might have a point, but not until then.

From rommel at suse.de  Wed May  5 06:11:56 2004
From: rommel at suse.de (Heiko Rommel)
Date: Wed May  5 06:08:48 2004
Subject: [Mailman-Developers] critical bug in Digest
Message-ID: <Pine.LNX.4.58.0405051140450.13733@poincare.suse.de>


Hi,

we experienced some problems with one of our major mailing lists which had the Digest turned on.

I finally found out that one of our users had misconfigured his MUA and send messages with
Content-Type: text/plain; charset*=utf-8342200235''utf-8%E2%80%9D
where 
Content-Type: text/plain; charset=utf-8
would be correct.

This caused Mailman 2.1.14 to

a) throw an exception:

Apr 30 13:39:51 2004 (13945) Traceback (most recent call last):
  File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 110, in _oneloop
    self._onefile(msg, msgdata)
  File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 160, in _onefile
    keepqueued = self._dispose(mlist, msg, msgdata)
  File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 130, in _dispose
    more = self._dopipeline(mlist, msg, msgdata, pipeline)
  File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline
    sys.modules[modname].process(mlist, msg, msgdata)
  File "/usr/lib/mailman/Mailman/Handlers/ToDigest.py", line 91, in process
    send_digests(mlist, mboxfp)
  File "/usr/lib/mailman/Mailman/Handlers/ToDigest.py", line 132, in send_digests
    send_i18n_digests(mlist, mboxfp)
  File "/usr/lib/mailman/Mailman/Handlers/ToDigest.py", line 306, in send_i18n_digests
    msg = scrubber(mlist, msg)
  File "/usr/lib/mailman/Mailman/Handlers/Scrubber.py", line 182, in process
    charset = part.get_content_charset(lcset)
  File "/usr/lib/mailman/pythonlib/email/Message.py", line 800, in get_content_charset
    charset = unicode(charset[2], pcharset).encode('us-ascii')
LookupError: unknown encoding


b) store the message in the digest.mbox, but shunt the message (so it was not delivered).

I tried the latest patches to Scrubber but that didn't help.

To my opinion, this is a very critial error since a single user can shut down the whole mailing list effectively.
My only option as an emergency action was to switch off the Digest option and
have a look into the very large digest.mbox :(

-- 
Heiko Rommel                             rommel@suse.de
SUSE Linux AG,     Maxfeldstr. 5,     D-90409 Nuernberg
T: +49 (0) 911 74053 0        F:  +49 (0) 911 741 77 55

From rommel at suse.de  Wed May  5 07:01:36 2004
From: rommel at suse.de (Heiko Rommel)
Date: Wed May  5 06:58:26 2004
Subject: [Mailman-Developers] reporting bugs with sourceforge ?!?
Message-ID: <Pine.LNX.4.58.0405051257390.13733@poincare.suse.de>


Hi,

hen going to the Bug tracker of Mailman 
(http://sourceforge.net/tracker/?group_id=103)
and clicking on Reporting I get

----------
Error

No Valid User Object 
----------------

I tried to report some bugs which I will sent to this list instead.

-- 
Heiko Rommel                             rommel@suse.de
SUSE Linux AG,     Maxfeldstr. 5,     D-90409 Nuernberg
T: +49 (0) 911 74053 0        F:  +49 (0) 911 741 77 55

From rommel at suse.de  Wed May  5 07:04:13 2004
From: rommel at suse.de (Heiko Rommel)
Date: Wed May  5 07:01:04 2004
Subject: [Mailman-Developers] problems with Generator.py
Message-ID: <Pine.LNX.4.58.0405051301370.13733@poincare.suse.de>


Hi,

I experienced this bug with 2.1.14:

May 05 12:49:21 2004 (2345) Uncaught runner exception: string payload expected: <type 'list'>
May 05 12:49:21 2004 (2345) Traceback (most recent call last):
  File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 110, in _oneloop
    self._onefile(msg, msgdata)
  File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 160, in _onefile
    keepqueued = self._dispose(mlist, msg, msgdata)
  File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 130, in _dispose
    more = self._dopipeline(mlist, msg, msgdata, pipeline)
  File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline
    sys.modules[modname].process(mlist, msg, msgdata)
  File "/usr/lib/mailman/Mailman/Handlers/SpamDetect.py", line 108, in process
    g.flatten(msg)
  File "/usr/lib/mailman/pythonlib/email/Generator.py", line 103, in flatten
    self._write(msg)
  File "/usr/lib/mailman/pythonlib/email/Generator.py", line 131, in _write
    self._dispatch(msg)
  File "/usr/lib/mailman/pythonlib/email/Generator.py", line 157, in _dispatch
    meth(msg)
  File "/usr/lib/mailman/pythonlib/email/Generator.py", line 200, in _handle_text
    raise TypeError, 'string payload expected: %s' % type(payload)
TypeError: string payload expected: <type 'list'>

May 05 12:49:21 2004 (2345) SHUNTING: 1083538445.4679279+8226bb6aa539e458952456fe2b2a0028198aa560


For debugging purposes, I attached the shunted message files.

-- 
Heiko Rommel                             rommel@suse.de
SUSE Linux AG,     Maxfeldstr. 5,     D-90409 Nuernberg
T: +49 (0) 911 74053 0        F:  +49 (0) 911 741 77 55
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1083538445.4679279+8226bb6aa539e458952456fe2b2a0028198aa560.pck
Type: application/octet-stream
Size: 6339 bytes
Desc: 
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20040505/4fccf15e/1083538445.46792798226bb6aa539e458952456fe2b2a0028198aa560.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1083538445.4679279+8226bb6aa539e458952456fe2b2a0028198aa560.db
Type: application/octet-stream
Size: 428 bytes
Desc: 
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20040505/4fccf15e/1083538445.46792798226bb6aa539e458952456fe2b2a0028198aa560-0001.obj
From rommel at suse.de  Wed May  5 07:06:48 2004
From: rommel at suse.de (Heiko Rommel)
Date: Wed May  5 07:03:38 2004
Subject: [Mailman-Developers] problems with Header.py
Message-ID: <Pine.LNX.4.58.0405051304370.13733@poincare.suse.de>


Hi,

I experienced this bug in 2.1.14:

May 05 12:49:21 2004 (2345) Uncaught runner exception: 
May 05 12:49:21 2004 (2345) Traceback (most recent call last):
  File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 110, in _oneloop
    self._onefile(msg, msgdata)
  File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 160, in _onefile
    keepqueued = self._dispose(mlist, msg, msgdata)
  File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 130, in _dispose
    more = self._dopipeline(mlist, msg, msgdata, pipeline)
  File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline
    sys.modules[modname].process(mlist, msg, msgdata)
  File "/usr/lib/mailman/Mailman/Handlers/CookHeaders.py", line 74, in process
    prefix_subject(mlist, msg, msgdata)
  File "/usr/lib/mailman/Mailman/Handlers/CookHeaders.py", line 237, in prefix_subject
    headerbits = decode_header(subject)
  File "/usr/lib/mailman/pythonlib/email/Header.py", line 113, in decode_header
    raise HeaderParseError
HeaderParseError

May 05 12:49:21 2004 (2345) SHUNTING: 1083566823.2704201+9f0320cd3fb74d1981b2484dafb3d406c4e3943a

For debugging purposes, I attached the shunted message files.

-- 
Heiko Rommel                             rommel@suse.de
SUSE Linux AG,     Maxfeldstr. 5,     D-90409 Nuernberg
T: +49 (0) 911 74053 0        F:  +49 (0) 911 741 77 55
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1083566823.2704201+9f0320cd3fb74d1981b2484dafb3d406c4e3943a.pck
Type: application/octet-stream
Size: 4635 bytes
Desc: 
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20040505/f348a541/1083566823.27042019f0320cd3fb74d1981b2484dafb3d406c4e3943a-0002.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1083566823.2704201+9f0320cd3fb74d1981b2484dafb3d406c4e3943a.db
Type: application/octet-stream
Size: 730 bytes
Desc: 
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20040505/f348a541/1083566823.27042019f0320cd3fb74d1981b2484dafb3d406c4e3943a-0003.obj
From moseley at hank.org  Wed May  5 12:36:03 2004
From: moseley at hank.org (Bill Moseley)
Date: Wed May  5 12:36:10 2004
Subject: [Mailman-Developers] Feature Request: Jerk Mode
Message-ID: <20040505163603.GC1586@hank.org>

I'm a 2.0.11 user.  I did look through the NEWS file; apologies if I
missed something new.

I'd like a subscription mode where someone will receive all messages,
but when they post their message is only delivered back to them.

I run a few lists where we have trollers and trouble makers.
Unsubscribing or moderating them doesn't help because they re-subscribe
with a new email address. Moderation of subscriptions and posts is not 
practical on some lists.

These people just post to get a reaction out of other list members.  The
best solution is to have people ignore them, but that's hard on a list
that is constantly changing.  So, this mode would allow a way for the
list owner to enforce people to ignore the posts.

I realize that it's not a perfect solution -- these people can still
re-subscribe with a new email address, but for many they may not realize
that they are the only one seeing their own messages.

Thanks,




-- 
Bill Moseley
moseley@hank.org


From rommel at suse.de  Wed May  5 12:53:12 2004
From: rommel at suse.de (Heiko Rommel)
Date: Wed May  5 12:50:04 2004
Subject: [Mailman-Developers] Maybe you guys can help me
In-Reply-To: <20040504021306.GA22619@allhats.xcski.com>
References: <20040504021306.GA22619@allhats.xcski.com>
Message-ID: <Pine.LNX.4.58.0405051848180.23043@poincare.suse.de>

On Mon, 3 May 2004, Paul Tomblin wrote:

> I tried asking this on mailman-users, and got totally ignored both times I
> asked.  Here is my problem:  One of my mailing list users has an ISP that
> refuses email for hours at a time, and the ISP that they get their email
> through, panix.com, sends a warning if it's undelivered for four hours.
> Problem is, mailman treats that warning as an error, and if it happens for
> a few days in a row (even if the problem corrects itself for part of the
> day and delivers the mail), it bounces her off my mailing lists.
> 
> The problem is that I don't know Python.  As far as I can tell, the fix to
> ignore these warnings should go in Mailman/Bouncers/Postfix.py, but that's
> all I can figure out.  Can somebody help me?
> 

While the developers are looking for the best way of handling such
delivery notifications ;) you might try to fiddle around with the Bounce
Processing Parameters (one of the top configuration categories).
Setting bounce_score_threshold to a higher while setting
bounce_info_stale_after to a really low value might ease your problems.

-- 
Heiko Rommel                             rommel@suse.de
SUSE Linux AG,     Maxfeldstr. 5,     D-90409 Nuernberg
T: +49 (0) 911 74053 0        F:  +49 (0) 911 741 77 55

From brad.knowles at skynet.be  Wed May  5 13:18:51 2004
From: brad.knowles at skynet.be (Brad Knowles)
Date: Wed May  5 13:35:16 2004
Subject: [Mailman-Developers] Feature Request: Jerk Mode
In-Reply-To: <20040505163603.GC1586@hank.org>
References: <20040505163603.GC1586@hank.org>
Message-ID: <p06002016bcbed1a369c6@[10.0.1.2]>

At 9:36 AM -0700 2004/05/05, Bill Moseley wrote:

>  I run a few lists where we have trollers and trouble makers.
>  Unsubscribing or moderating them doesn't help because they re-subscribe
>  with a new email address. Moderation of subscriptions and posts is not
>  practical on some lists.

	Even if you required approval for the subscriptions, they'd still 
find a way to get through.  You have to moderate each and every post, 
at least for those subscribers who are causing problems.

>  These people just post to get a reaction out of other list members.  The
>  best solution is to have people ignore them, but that's hard on a list
>  that is constantly changing.  So, this mode would allow a way for the
>  list owner to enforce people to ignore the posts.

	They would notice that they're not getting a reaction and 
re-subscribe under another name.  You can't stop them.

>  I realize that it's not a perfect solution -- these people can still
>  re-subscribe with a new email address, but for many they may not realize
>  that they are the only one seeing their own messages.

	Sooner or later, they will.  I don't think that this is something 
that you can solve.  If you can't moderate the list, or at least 
moderate the problem users (and maybe moderate all new subscribers by 
default), and you can't get these people to behave, you're screwed.

-- 
Brad Knowles, <brad.knowles@skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

   SAGE member since 1995.  See <http://www.sage.org/> for more info.

From moseley at hank.org  Wed May  5 13:50:53 2004
From: moseley at hank.org (Bill Moseley)
Date: Wed May  5 13:51:04 2004
Subject: [Mailman-Developers] Feature Request: Jerk Mode
In-Reply-To: <p06002016bcbed1a369c6@[10.0.1.2]>
References: <20040505163603.GC1586@hank.org> <p06002016bcbed1a369c6@[10.0.1.2]>
Message-ID: <20040505175053.GB24842@hank.org>

On Wed, May 05, 2004 at 07:18:51PM +0200, Brad Knowles wrote:
> At 9:36 AM -0700 2004/05/05, Bill Moseley wrote:
> 
> > I run a few lists where we have trollers and trouble makers.
> > Unsubscribing or moderating them doesn't help because they re-subscribe
> > with a new email address. Moderation of subscriptions and posts is not
> > practical on some lists.
> 
> 	Even if you required approval for the subscriptions, they'd still 
> find a way to get through.  You have to moderate each and every post, 
> at least for those subscribers who are causing problems.

When I turned on moderation they resubscribed.  So I'd need to moderate
everyone.  White listing would help on smaller lists, I suppose.

Both banning and moderation are obvious to the sender.

> > These people just post to get a reaction out of other list members.  The
> > best solution is to have people ignore them, but that's hard on a list
> > that is constantly changing.  So, this mode would allow a way for the
> > list owner to enforce people to ignore the posts.
> 
> 	They would notice that they're not getting a reaction and 
> re-subscribe under another name.  You can't stop them.

I agree, that's true for some.  It would slow the problem down in some
cases, though.  On one smaller list we managed to stop the behavior by
asking everyone to not respond.  So it does help in some cases.

No, not an answer.  It would just be another tool.  Like spam filtering
-- it's nowhere perfect, but I still use filtering as it helps reduce
the problem.

Thanks for the feedback,  and thanks for Mailman!

-- 
Bill Moseley
moseley@hank.org


From wheakory at isu.edu  Wed May  5 14:34:14 2004
From: wheakory at isu.edu (Kory Wheatley)
Date: Wed May  5 14:37:43 2004
Subject: [Mailman-Developers] Mailman Size Issues
Message-ID: <409933A6.6090909@isu.edu>

I have a critical situation that I need addressed, and it deals with 
large messages being sent to mailman mailing lists.

Currently, we have a lot of  large mailing lists (some have 10,000 to 
15,000 subscribers) and  some of these lists is all Faculty/Staff email 
subscribers that have an account on our mail server.  All messages sent 
to these lists are moderated.   Here's the problem, when some of these 
pending messages are accepted to be sent, and one of the messages 
happens to be 5mb in size, that amount of email that is sent to our mail 
server all at once, "kills us", and someday if a larger one is sent, it 
will fill up our mail stores and corrupt our mail server. 

We can configure our mail server to not accept a message over 5 meg and 
that would solve the problem, but our University Advisory Committee 
would not allow  that.  They have approved that it be set to 10 meg, for 
messages be sent to only one recipient, but individuals who use the 
mailing lists, abuse this. Sometimes messages get approved that 
shouldn't and we run into this problem

All get to my point, is there a way that if a moderator tries to approve 
a message that is over 1 meg, that maybe some custom python code could 
be developed to pop up a message and say "Only messages below 1 meg can 
be approved"  and have the message discarded, or tell the user the only 
option they have is to discard the message.

I know there's the "max_message_size" option you can set, but that still 
sends the message to the pending database and they can still accept the 
message,  rather than discard the message when its above that size.

Any Solution?  I know you will want to say change your policy on your 
mail server, but at this point it's not a option.

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


From qralston+ml.mailman-developers at andrew.cmu.edu  Wed May  5 19:03:14 2004
From: qralston+ml.mailman-developers at andrew.cmu.edu (James Ralston)
Date: Wed May  5 19:03:23 2004
Subject: suggestion for Full Customization [Mailman-Developers]
Message-ID: <6F422DEF013753DE2487ED0B@pcmy.sei.cmu.edu>

Mailman 2.1.4, Mailman/Handlers/CookHeaders.py, line 138:

        # The To field normally contains the list posting address.  However
        # when messages are fully personalized, that header will get
        # overwritten with the address of the recipient.  We need to get the
        # posting address in one of the recipient headers or they won't be
        # able to reply back to the list.  It's possible the posting address
        # was munged into the Reply-To header, but if not, we'll add it to a
        # Cc header.  BAW: should we force it into a Reply-To header in the
        # above code?
        if mlist.personalize == 2 and mlist.reply_goes_to_list <> 1:
            # Watch out for existing Cc headers, merge, and remove dups.  Note
            # that RFC 2822 says only zero or one Cc header is allowed.
            new = []
            d = {}
            for pair in getaddresses(msg.get_all('cc', [])):
                add(pair)
            i18ndesc = uheader(mlist, mlist.description)
            add((str(i18ndesc), mlist.GetListEmail()))
            del msg['Cc']
            msg['Cc'] = COMMASPACE.join([formataddr(pair) for pair in new])

Question: why was this done?

If I have set the "personalize" option to "Full Personalization", a
very likely reason why I have done so is because I don't *WANT* the
recipient to reply back to the list--or, for that matter, even realize
that the message was sent through a mailing list at all.  I want the
recipient to see an individual message that looked like it was sent
*from* an individual person *to* an individual person.

Adding the list address to the CC header perfectly defeats this.

While I can address this locally simply by excising the above code
snippet, I'd rather see this issue addressed upstream.

Would it make sense to split the "Full Personalization" setting into
its own option?  Meaning, make the existing personalize Option a
yes/no toggle, and create another option to specify how to customize
the headers:

    - To: header is listname; recipient address does not appear (default)
    - To: header is recipient; CC: header is listname
    - To: header is recipient; listname does not appear

If someone would be willing to double-check my Python code (and
proofread my documentation), I'd be willing to implement a patch to
perform the above split.

Thoughts?

-- 
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA


From qralston+ml.mailman-developers at andrew.cmu.edu  Wed May  5 20:57:47 2004
From: qralston+ml.mailman-developers at andrew.cmu.edu (James Ralston)
Date: Wed May  5 20:57:53 2004
Subject: customize auto-response Subject header? [Mailman-Developers]
Message-ID: <2FE5EC8A7605E5D083276F38@pcmy.sei.cmu.edu>

The Subject: header of auto-responses is fixed as:

    Subject: Auto-response for your message to the "%(listname)" mailing list

I'd really like to be able to customize that.  E.g.:

    Subject: thanks for your submission

Or, with variable substitution:

    Subject: thanks for your submission to %(listname)

Or even:

    Subject: Re: %(old_subject_header_contents)

I don't think allow list owners to customize the format of the
Subject: header of auto-replies is unreasonable.  I haven't studied
the code closely yet, but I don't think it would be that complicated,
either.

Thoughts?

Regards,
James


From brad.knowles at skynet.be  Thu May  6 04:26:05 2004
From: brad.knowles at skynet.be (Brad Knowles)
Date: Thu May  6 04:41:01 2004
Subject: suggestion for Full Customization [Mailman-Developers]
In-Reply-To: <6F422DEF013753DE2487ED0B@pcmy.sei.cmu.edu>
References: <6F422DEF013753DE2487ED0B@pcmy.sei.cmu.edu>
Message-ID: <p0600201fbcbfa6a73787@[10.0.1.2]>

At 7:03 PM -0400 2004/05/05, James Ralston wrote:

>  If I have set the "personalize" option to "Full Personalization", a
>  very likely reason why I have done so is because I don't *WANT* the
>  recipient to reply back to the list--or, for that matter, even realize
>  that the message was sent through a mailing list at all.  I want the
>  recipient to see an individual message that looked like it was sent
>  *from* an individual person *to* an individual person.
>
>  Adding the list address to the CC header perfectly defeats this.

	This is a mailing list.  Mailman is a mailing list manager.  It 
is not a "hidden address so you can spam" manager.  We're not trying 
to hide anything here, and I doubt that anyone is going to be 
interested to see code in the mainstream package that would try to 
address this "problem".

-- 
Brad Knowles, <brad.knowles@skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

   SAGE member since 1995.  See <http://www.sage.org/> for more info.

From shaikli at yahoo.com  Fri May  7 02:48:32 2004
From: shaikli at yahoo.com (Nadim Shaikli)
Date: Fri May  7 02:48:36 2004
Subject: [Mailman-Developers] envelope header checking
Message-ID: <20040507064832.67695.qmail@web14925.mail.yahoo.com>

I have a number of lists that I administer that seem to have come across
a nasty quirk.  I use postfix and spamassassin to keep spam in check but
recently I've noticed something different.

I disallow any posts coming in externally with @my_domain via postfix
(it uses the envelope sender to do the checks).  Mailman, on the other
hand, uses the header From: field and thus the problem.

I've recently got mails that looks like this,

 From him@outside.com
 Date: blah blah
 From: me@my_domain.com

so postfix processes it and allows it into my queues (after all it is not
being spoofed - the envelope (first From) is clean).  Mailman though sizes
up this email based on the From: header field and denotes it a locally
generate post which I allow irrespective of subscription (I have non-member
filtering to allow posts from '.*@my_domain.com' through via the
'accept_these_nonmembers' setting).

So I have 2 questions,

 1. Anyone know of a decent way to make sure that both the envelope sender
    and the noted From header field do in fact match ? else reject/discard
    the email.

 2. Does mailman allow one to check the envelope sender instead of the
    From: header field ?  That way I know both postfix and mailman are
    looking at the same thing.

I'm using postfix-2.0.16; question-1 above also needs to account for myself
being able to mail out without issue (ie. in case someone suggests header
filtering within postfix -- that would stop internal emails from going out
and I'm unable to upgrade to postfix-2.1 just yet which seems to have hooks
for this now).

Regards,

 - Nadim



	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 

From jwt at onjapan.net  Fri May  7 03:45:16 2004
From: jwt at onjapan.net (Jim Tittsler)
Date: Fri May  7 03:45:26 2004
Subject: [Mailman-Developers] Mailman Size Issues
In-Reply-To: <409933A6.6090909@isu.edu>
References: <409933A6.6090909@isu.edu>
Message-ID: <7B723014-9FFA-11D8-A3E7-000A957919FA@onjapan.net>

On May 6, 2004, at 03:34, Kory Wheatley wrote:

> All get to my point, is there a way that if a moderator tries to 
> approve a message that is over 1 meg, that maybe some custom python 
> code could be developed to pop up a message and say "Only messages 
> below 1 meg can be approved"  and have the message discarded, or tell 
> the user the only option they have is to discard the message.

If the administrator isn't allowed to do anything but discard the 
message, wouldn't it be better to just discard (or reject with notice 
to the sender) at the time that the message is received rather than 
holding it for discard/reject?  There are a couple of ways you could do 
that.
1. The quick one is modify Mailman/Handlers/Hold.py so that instead of 
doing hold_for_approval() you raised Errors.RejectMessage (or 
Errors.DiscardMessage) if the message is too big.
--- Hold.py-2.1.4       2003-12-27 07:55:45.000000000 +0900
+++ Hold.py     2004-05-07 16:35:05.000000000 +0900
@@ -177,8 +177,12 @@
          for line in email.Iterators.body_line_iterator(msg):
              bodylen += len(line)
          if bodylen/1024.0 > mlist.max_message_size:
-            hold_for_approval(mlist, msg, msgdata,
-                              MessageTooBig(bodylen, 
mlist.max_message_size))
+           raise Errors.RejectMessage, Utils.wrap('''Your message
+exceeds the maximum size allowed for mailing list messages and has
+not been distributed.
+
+For more information on mailing list policy, visit
+http://institution.edu/mail/rules.html or contact 
admin@institution.edu''')
              # no return

The disadvantage is that you have to remember to make this change each 
time you upgrade Mailman.

2. A cleaner way is to add a custom site handler early in the message 
pipeline that checks the message size (steal the code from Hold.py :-) 
and raises the appropriate error.  Add it to your GLOBAL_PIPELINE in 
your mm_cfg.py.  Good for other site-specific hacks.

But I suppose you could modify Mailman/Cgi/admindb.py to do what you 
ask.  Don't create the button for "Accept" (or allow the accept 
response so nobody gets tricky) for large messages.  You would want to 
unroll the loop so that the "Reject"/"Discard" buttons are available 
for each message rather than for each sender.

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


From stephen at xemacs.org  Fri May  7 06:57:52 2004
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri May  7 06:58:02 2004
Subject: [Mailman-Developers] Maybe you guys can help me
In-Reply-To: <391C06A4-9DF3-11D8-A2E1-0003934516A8@plaidworks.com> (Chuq Von
	Rospach's message of "Tue, 4 May 2004 10:48:16 -0700")
References: <20040504021306.GA22619@allhats.xcski.com>
	<1083661610.8201.12.camel@angua.localnet>
	<p0600202dbcbd261a1606@[10.0.1.2]>
	<20040504110326.GB4994@allhats.xcski.com> <28242.1083680751@kanga.nu>
	<E8DAE174C87231754F5BA626@[192.168.20.2]>
	<4097BDB0.20906@nleaudio.com>
	<20040504160806.GA14259@allhats.xcski.com>
	<20040504173819.M98054@nleaudio.com>
	<391C06A4-9DF3-11D8-A2E1-0003934516A8@plaidworks.com>
Message-ID: <87d65g7bdb.fsf@tleepslib.sk.tsukuba.ac.jp>

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

    Chuq> my current thought on that is:

    Chuq> http://www.plaidworks.com/chuqui/blog/001447.html

My now-ancient thought on this is

    http://turnbull.sk.tsukuba.ac.jp/Tools/Attitude/

Warning, it swears like a bounce.

    Chuq> so my policy is now simple: if you bounce it back, I'll
    Chuq> treat it like a bounce. If it has the word "spam" in it
    Chuq> anywhere, it'll be treated like a complaint against my
    Chuq> server, and suffer immediate unsubscription.

Thank you for taking point on this.  I get so tired of the "spam
fighters" who produce more unwanted mail than they receive!

    Chuq> and I suggest Mailman as a package take that approach, if we
    Chuq> want to have any hope of convincing admins to get their
    Chuq> bleeding act together.

If you want that to get anywhere, you're going to have to sharpen up
the language, though.  Many users have very little power over their
ISP and strong reason not to change (their ISP also provides their
income).  List admins tend to sympathize with their subscribers.  Yes,
we need to take the long view, but we don't want to go destroying
villages to save them, either.

Also, it's not really the mail admins.  I know a few "incompetent"
admins, but really they're just average dudes who lack the time.  They
_must_ cut down the spam and virus flow, so they choose a package that
has some reputation for doing just that, install it, and dismiss the
occasional complaint about excessive bounces or lost mail due to false
positives as cranks and casualties of war.

IMO, it's not the admins we need to punish, it's the _scanner
distributors_ who are providing software that by factory default
pollutes the whole 'net.


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

From neves at samba-choro.com.br  Fri May  7 12:16:13 2004
From: neves at samba-choro.com.br (Paulo Eduardo Neves)
Date: Fri May  7 12:00:29 2004
Subject: [Mailman-Developers] Allowing post just if a header is present
Message-ID: <200405071316.13164.neves@samba-choro.com.br>

I've tried to have a list open, manually approving the messages of 
non-subscribers, but due to the amount of spam and virus, I can't handle the 
workload any more. 

I want to allow posting of non-subscribers just if they use a form in my 
webpage (no direct emailing to the list address). It looks like that it isn't 
possible to automatically approve a message just if a header is present. Any 
tips on how to implement it?

regards,
-- 
Paulo Eduardo Neves
Agenda do Samba & Choro, o boteco virtual do samba e choro
http://www.samba-choro.com.br 

From terri at zone12.com  Sat May  8 00:33:58 2004
From: terri at zone12.com (Terri Oda)
Date: Sat May  8 00:33:43 2004
Subject: [Mailman-Developers] Feature Request: Jerk Mode
In-Reply-To: <20040505163603.GC1586@hank.org>
References: <20040505163603.GC1586@hank.org>
Message-ID: <EC76037E-A0A8-11D8-81D0-000D934FBF38@zone12.com>


On May 5, 2004, at 12:36 PM, Bill Moseley wrote:
> I'd like a subscription mode where someone will receive all messages,
> but when they post their message is only delivered back to them.

I don't think this is really appropriate for Mailman as a whole, but it 
shouldn't be impossible for you to implement.  How's your Python?  If 
you're not too squeamish about poking around in there yourself, I think 
you should be able to go take a look at the code designed so people 
don't get their own posts, and do the opposite for people with another 
bit set.  It's going to mess with your user records and such to have 
this extra setting, but if these people are becoming that much of a 
problem, it might be worth doing.

If you're not into poking around in Mailman, you could do this before 
the message makes it to Mailman -- set yourself up a script that, if 
the message comes from a given set of addresses, sends a message back 
that looks like it came from mailman (not that hard to forge) 
containing that message.  Then don't bother to send the message on to 
mailman.  This allows you to keep your solution separate from mailman 
so you won't have to remember to change code again and again when you 
upgrade (although if your list appearance changes, your "jerk" might 
notice the discrepancy... most people tune that sort of thing out 
though).  If you're not up for programming this from scratch, you could 
probably adapt some "vacation" mail script for the purpose -- I'm sure 
a web search would turn up something appropriate.

  Terri


From mhaecker at mac.com  Sat May  8 09:23:28 2004
From: mhaecker at mac.com (Martin =?iso-8859-1?Q?H=E4cker?=)
Date: Sat May  8 09:22:59 2004
Subject: [Mailman-Developers] Where to start Implement this?
Message-ID: <p06100503bcc282829868@[192.168.1.3]>

Hi there,

Could you please give me some advice about where to start implement this?

I want to create an option that allows my users to have the 
mailinglist set a reply-to header to itself in their e-mails. (Please 
no discussion about wether this is bad or not - I've read 
<http://www.unicom.com/pw/reply-to-harmful.html> and 
<http://www.metasystema.net/essays/reply-to.mhtml> and also had a 
look at the archive of the mailman-users list)

Though I want it - and I want it so badly I'm going to implement it myself.

As far as a quick investigation has shown I will need to add the 
preference in MemberAdoptor.py and some of it's subclasses (which?) 
and then change Decorator.py to write the Reply-To if the user 
whiches for it.

Would this be the right way to do it? And is there any other place I 
need to change to make this work?

Thanks a lot
cu Martin
-- 
dont.wanna.tell
[ot]coder - hehe

From jelly+mailman-dev at mail.iskon.hr  Sat May  8 10:35:05 2004
From: jelly+mailman-dev at mail.iskon.hr (Zoran Dzelajlija)
Date: Sat May  8 11:18:11 2004
Subject: [Mailman-Developers] upgrade 2.0 -> 2.1: heldmsgs?
Message-ID: <20040508143505.1915.4.NOFFLE@islands.iskon.hr>

Hi.

I have both Mailman 2.0 and 2.1 installed on a machine, and wish to migrate
a number of lists from Mailman 2.0.13 to the latest 2.1 version.  However, I
don't want to lose any of our customers data and make it as transparent as
possible, so I'd like to convert everything, including all the stuff from
the data/ directory, heldmsg-* and the pending subscriptions.

Is there a script to convert the 2.0 heldmsg-*.txt to current heldmsg-*.pck
style, or if I am to write one, where should I start from?  What about
pending subscriptions?

Zoran


From terri at zone12.com  Sat May  8 13:13:31 2004
From: terri at zone12.com (Terri Oda)
Date: Sat May  8 13:13:14 2004
Subject: [Mailman-Developers] Where to start Implement this?
In-Reply-To: <p06100503bcc282829868@[192.168.1.3]>
References: <p06100503bcc282829868@[192.168.1.3]>
Message-ID: <07A9B0E6-A113-11D8-81D0-000D934FBF38@zone12.com>


On May 8, 2004, at 9:23 AM, Martin H?cker wrote:
> I want to create an option that allows my users to have the 
> mailinglist set a reply-to header to itself in their e-mails.

> Could you please give me some advice about where to start implement 
> this?

Um.  No need to implement it -- it's built in!

Just look for the reply_goes_to_list option in the list admin stuff.  
If you're going through the web interface, just search for that string 
in the general options page and it's there in the middle of the page.  
Do take a look at the other settings for Reply-to's.  What you probably 
want is to have the header stripped then set to the list, since 
otherwise anytime someone does have a reply-to set it becomes <that 
address> + <list address> which mostly leads to duplicates for people.  
But of course, your list members may prefer that.

You can also have this be the default on your server, if I recall 
correctly, by putting it in your mailman config file.

  Terri


From david at midrange.com  Sat May  8 16:35:49 2004
From: david at midrange.com (David Gibbs)
Date: Sat May  8 16:40:23 2004
Subject: [Mailman-Developers] Re: Feature Request: Jerk Mode
In-Reply-To: <20040505163603.GC1586@hank.org>
References: <20040505163603.GC1586@hank.org>
Message-ID: <c7jgb6$932$1@sea.gmane.org>

Bill Moseley wrote:

> I'd like a subscription mode where someone will receive all messages,
> but when they post their message is only delivered back to them.

I'm on 2.1.4 and using the "moderate on subscription" ... thus new 
subscribers are moderated initially ... but once they post a good 
message, I remove the moderation flag.

I had a idiot subscribe to the list, post a advertisement (which isn't 
allowed) and then unsubscribe.

The 'initial moderation' feature works well for this.  Since only a 
handful of folks on my list actually post, it's not a big chore to 
manually approve the first post.

david



-- 
If you have an apple and I have an apple and we exchange apples then you 
and I will still each have one apple. But if you have an idea and I have 
an idea and we exchange these ideas, then each of us will have two ideas.

- George Bernard Shaw


From prodos at prodos.com  Sun May  9 02:06:47 2004
From: prodos at prodos.com (prodos@prodos.com)
Date: Sun May  9 02:06:51 2004
Subject: [Mailman-Developers] Can moderator edit subject line and body of
	message?
Message-ID: <20040509060647.7433.qmail@webmail-2-6.mesa1.secureserver.net>

From: Prodos (Melbourne, Australia)

Good afternoon.

[Part of this post was recently sent to the mailman-users list but
didn't get a response. So I'm taking the liberty of posting it to
the mailman-developers list. I hope that's okay. Thanks.]

I coordinate a whole lot of non-profit projects (promoting free trade and
related issues) and for years have been using YahooGroups/eGroups.

I currently have about 200 lists set up with YahooGroups (each city involved
in the campaigns has its own local discussion list, hence the quantity of lists.)

For a couple of months now I've been "shopping about" for an
alternative list service and I really like Mailman. 

However, the main problem I have with it is:

It doesn't allow the subject line and the body of the message
to be edited by the moderator before the message is sent 
through to members. 

YahooGroups allows this to be done very easily.

Searching the mailman-user archives I've come across the following patch:

"[ 644129 ] Edit held message header/body" available @
https://sourceforge.net/tracker/index.php?func=detail&aid=644129&group_id=103&atid=300103

The description says this patch allows "full editing of headers and bodies of messages being
held for approval in Mailman 2.1"

>From the description it seems this patch *does* make it possible to edit
the body of a post. But I'm not sure, does it also allow editing of the subject line?
i.e. Does "header" mean the same thing as "subject line"?

Questions:

Is it simple/easy/straightforward to do the required editing once this patch is installed?

Is there a better patch available for the job?

Is it a well tested patch?

Why isn't such editing a standard part of Mailman?
Is it because Mailman's developers think such editing is wrong?
Or is it because there's not much call for such a function?

Thank you for any assistance or suggestions on the above!


=]:-)

Best Wishes,

PRODOS

http://prodos.com

"Discover the power. Of ideas!"








-




From mhaecker at mac.com  Sun May  9 04:20:11 2004
From: mhaecker at mac.com (Martin =?iso-8859-1?Q?H=E4cker?=)
Date: Sun May  9 04:19:38 2004
Subject: [Mailman-Developers] Where to start Implement this?
In-Reply-To: <07A9B0E6-A113-11D8-81D0-000D934FBF38@zone12.com>
References: <p06100503bcc282829868@[192.168.1.3]>
	<07A9B0E6-A113-11D8-81D0-000D934FBF38@zone12.com>
Message-ID: <p0610050cbcc3993cbd78@[192.168.1.3]>

At 13:13 Uhr -0400 08.05.2004, Terri Oda wrote:
>On May 8, 2004, at 9:23 AM, Martin H?cker wrote:
>>I want to create an option that allows my users 
>>to have the mailinglist set a reply-to header 
>>to itself in their e-mails.
>
>>Could you please give me some advice about where to start implement this?
>
>Just look for the reply_goes_to_list option in 
>the list admin stuff.  If you're going through 
>the web interface, just search for that string 
>in the general options page and it's there in 
>the middle of the page.  Do take a look at the 
>other settings for Reply-to's.  What you 
>probably want is to have the header stripped 
>then set to the list, since otherwise anytime 
>someone does have a reply-to set it becomes 
><that address> + <list address> which mostly 
>leads to duplicates for people.  But of course, 
>your list members may prefer that.

Well, if I'm not completely of track (which I may 
well be) then this setting will apply to all 
users at once - which is not what I need.

I need this setting to apply for some users only so I can't set it globally.

But I'd love to be proven wrong.

cu Martin
-- 
dont.wanna.tell
[ot]coder - hehe

From terri at zone12.com  Sun May  9 11:54:41 2004
From: terri at zone12.com (Terri Oda)
Date: Sun May  9 11:54:24 2004
Subject: [Mailman-Developers] Where to start Implement this?
In-Reply-To: <p0610050cbcc3993cbd78@[192.168.1.3]>
References: <p06100503bcc282829868@[192.168.1.3]>
	<07A9B0E6-A113-11D8-81D0-000D934FBF38@zone12.com>
	<p0610050cbcc3993cbd78@[192.168.1.3]>
Message-ID: <2F1D714D-A1D1-11D8-81D0-000D934FBF38@zone12.com>

> Well, if I'm not completely of track (which I may well be) then this 
> setting will apply to all users at once - which is not what I need.
>
> I need this setting to apply for some users only so I can't set it 
> globally.

Ahh.  Per user is harder, yes -- it wasn't clear in your original post 
that that's what you wanted.  I don't know offhand all the things you'd 
need to change for this, but it *sounds* like you're on the right 
track.


From mhaecker at mac.com  Sun May  9 13:10:19 2004
From: mhaecker at mac.com (Martin =?iso-8859-1?Q?H=E4cker?=)
Date: Sun May  9 13:09:41 2004
Subject: [Mailman-Developers] Where to start Implement this?
In-Reply-To: <2F1D714D-A1D1-11D8-81D0-000D934FBF38@zone12.com>
References: <p06100503bcc282829868@[192.168.1.3]>
	<07A9B0E6-A113-11D8-81D0-000D934FBF38@zone12.com>
	<p0610050cbcc3993cbd78@[192.168.1.3]>
	<2F1D714D-A1D1-11D8-81D0-000D934FBF38@zone12.com>
Message-ID: <p06100504bcc414d9b64f@[192.168.1.3]>

At 11:54 Uhr -0400 09.05.2004, Terri Oda wrote:
>>Well, if I'm not completely of track (which I may well be) then 
>>this setting will apply to all users at once - which is not what I 
>>need.
>>
>>I need this setting to apply for some users only so I can't set it globally.
>
>Ahh.  Per user is harder, yes -- it wasn't clear in your original 
>post that that's what you wanted.  I don't know offhand all the 
>things you'd need to change for this, but it *sounds* like you're on 
>the right track.

I'm a bit confused by the vocabulary used by Jim Tittsler. What he 
said sounded like not every mail (to a user) is processed on its own 
but instead many of them are built and send as one mail?

That would go aginst my understanding, but hey... :)

cu Martin
-- 
dont.wanna.tell
[ot]coder - hehe

From brad.knowles at skynet.be  Sun May  9 13:52:46 2004
From: brad.knowles at skynet.be (Brad Knowles)
Date: Sun May  9 13:53:14 2004
Subject: [Mailman-Developers] Where to start Implement this?
In-Reply-To: <p06100504bcc414d9b64f@[192.168.1.3]>
References: <p06100503bcc282829868@[192.168.1.3]>
	<07A9B0E6-A113-11D8-81D0-000D934FBF38@zone12.com>
	<p0610050cbcc3993cbd78@[192.168.1.3]>
	<2F1D714D-A1D1-11D8-81D0-000D934FBF38@zone12.com>
	<p06100504bcc414d9b64f@[192.168.1.3]>
Message-ID: <p06002036bcc420079cf6@[10.0.1.2]>

At 7:10 PM +0200 2004/05/09, Martin H?cker wrote:

>  I'm a bit confused by the vocabulary used by Jim Tittsler. What he
>  said sounded like not every mail (to a user) is processed on its own
>  but instead many of them are built and send as one mail?

	That's correct.  That's how mailing lists usually work.  They 
take one input message, potentially add things like headers and 
footers, then send that back out to the list recipients -- tens, or 
hundreds, or thousands of addresses.

	They typically group as many recipients together as they can, so 
that they send one copy of the message, addressed to multiple users.

-- 
Brad Knowles, <brad.knowles@skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

   SAGE member since 1995.  See <http://www.sage.org/> for more info.

From mhaecker at mac.com  Sun May  9 14:28:08 2004
From: mhaecker at mac.com (Martin =?iso-8859-1?Q?H=E4cker?=)
Date: Sun May  9 14:27:30 2004
Subject: [Mailman-Developers] Where to start Implement this?
In-Reply-To: <p06002036bcc420079cf6@[10.0.1.2]>
References: <p06100503bcc282829868@[192.168.1.3]>
	<07A9B0E6-A113-11D8-81D0-000D934FBF38@zone12.com>
	<p0610050cbcc3993cbd78@[192.168.1.3]>
	<2F1D714D-A1D1-11D8-81D0-000D934FBF38@zone12.com>
	<p06100504bcc414d9b64f@[192.168.1.3]>
	<p06002036bcc420079cf6@[10.0.1.2]>
Message-ID: <p06100506bcc42791195a@[192.168.1.3]>

>>  I'm a bit confused by the vocabulary used by Jim Tittsler. What he
>>  said sounded like not every mail (to a user) is processed on its own
>>  but instead many of them are built and send as one mail?
>
>	That's correct.  That's how mailing lists usually work.  They 
>take one input message, potentially add things like headers and 
>footers, then send that back out to the list recipients -- tens, or 
>hundreds, or thousands of addresses.
>
>	They typically group as many recipients together as they can, 
>so that they send one copy of the message, addressed to multiple 
>users.

Now this sounds logical from a performance point of view.

Hm, I tried to find some design documention/overview on the list.org 
site, but I couldn't find anything, could somebody give me a hint 
about this?

Thanks again,
cu Martin
-- 
dont.wanna.tell
[ot]coder - hehe

From brad.knowles at skynet.be  Sun May  9 16:44:50 2004
From: brad.knowles at skynet.be (Brad Knowles)
Date: Sun May  9 16:45:56 2004
Subject: [Mailman-Developers] Where to start Implement this?
In-Reply-To: <p06100506bcc42791195a@[192.168.1.3]>
References: <p06100503bcc282829868@[192.168.1.3]>
	<07A9B0E6-A113-11D8-81D0-000D934FBF38@zone12.com>
	<p0610050cbcc3993cbd78@[192.168.1.3]>
	<2F1D714D-A1D1-11D8-81D0-000D934FBF38@zone12.com>
	<p06100504bcc414d9b64f@[192.168.1.3]>
	<p06002036bcc420079cf6@[10.0.1.2]>
	<p06100506bcc42791195a@[192.168.1.3]>
Message-ID: <p0600203bbcc448a421de@[10.0.1.2]>

At 8:28 PM +0200 2004/05/09, Martin H?cker wrote:

>  Hm, I tried to find some design documention/overview on the list.org
>  site, but I couldn't find anything, could somebody give me a hint about
>  this?

	The documentation that is available is at 
<http://www.list.org/docs.html>.  Beyond that, I am not aware of 
anything.

-- 
Brad Knowles, <brad.knowles@skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

   SAGE member since 1995.  See <http://www.sage.org/> for more info.

From qralston+ml.mailman-developers at andrew.cmu.edu  Mon May 10 02:54:06 2004
From: qralston+ml.mailman-developers at andrew.cmu.edu (James Ralston)
Date: Mon May 10 02:54:10 2004
Subject: suggestion for Full Customization [Mailman-Developers]
Message-ID: <B9D1EBBA4EC2F00FA666360C@shieldbreaker.l33tskillz.org>

Brad,

On 2004-05-06 at 10:26:05+02 Brad Knowles <brad.knowles@skynet.be> wrote:

> At 7:03 PM -0400 2004/05/05, James Ralston wrote:
> 
> > If I have set the "personalize" option to "Full Personalization",
> > a very likely reason why I have done so is because I don't *WANT*
> > the recipient to reply back to the list--or, for that matter, even
> > realize that the message was sent through a mailing list at all.
> > I want the recipient to see an individual message that looked like
> > it was sent *from* an individual person *to* an individual person.
> > 
> > Adding the list address to the CC header perfectly defeats this.
> 
> This is a mailing list.  Mailman is a mailing list manager.  It is
> not a "hidden address so you can spam" manager.  We're not trying to
> hide anything here, and I doubt that anyone is going to be
> interested to see code in the mainstream package that would try to
> address this "problem".

I've been lurking on these lists for a few months now.  In that time,
I've seen you generally act friendly and helpful towards others.  So,
I'm going to give you the benefit of the doubt and assume that your
rude and unprofessional reply was a result of a really bad mood, a
complete misinterpretation of what I was suggesting, or both.

Given these two points:

1.  Mailman already allows list owners to configure their lists so
    that only a few select people are permitted to post.  The typical
    case in which a list owner would want to do this is the situation
    where a single person wants to send "announcement" -type messages
    to a non-trivial number of recipients.

2.  Mailman already has personalization features, so that messages can
    be customized on a per-user basis.  One of the personalization
    features is the ability to customize the "To:" header for each
    recipient, and move the list address to the "CC:" header.

...why would you even *want* to have the listname for an announcement
list exposed in the To and/or CC header of messages sent through the
list?  If a recipient replies to the list, it's just going to go to
the moderators, right?  In most cases, the person who is sending the
messages will *be* the moderator.  Why not just bypass this
indirection and have the replies go directly to the sender (i.e., the
moderator)?

One counter-argument would be that if a list had multiple moderators,
you would probably want people to reply to the list (instead of one of
the moderators individually), so that all of the moderators could
possibly act upon the reply.  But that's actually an argument for
permitting the list owners to decide where they want the list address
to appear (if at all).

Which is what I not only suggested, but *volunteered to contribute*.

Are the specifics of what I'm suggesting clearer now?


From brad.knowles at skynet.be  Mon May 10 04:50:59 2004
From: brad.knowles at skynet.be (Brad Knowles)
Date: Mon May 10 04:51:29 2004
Subject: suggestion for Full Customization [Mailman-Developers]
In-Reply-To: <B9D1EBBA4EC2F00FA666360C@shieldbreaker.l33tskillz.org>
References: <B9D1EBBA4EC2F00FA666360C@shieldbreaker.l33tskillz.org>
Message-ID: <p06002000bcc4eee70d2f@[10.0.1.2]>

At 2:54 AM -0400 2004/05/10, James Ralston wrote:

>  ...why would you even *want* to have the listname for an announcement
>  list exposed in the To and/or CC header of messages sent through the
>  list?  If a recipient replies to the list, it's just going to go to
>  the moderators, right?  In most cases, the person who is sending the
>  messages will *be* the moderator.  Why not just bypass this
>  indirection and have the replies go directly to the sender (i.e., the
>  moderator)?

	One of the fundamental concepts of a mailing list is that people 
know that the content is being shared with multiple recipients, and 
anything they receive via the list is public knowledge (at least, to 
the other list recipients), and anything they post will likewise be 
public knowledge.  By breaking this concept and making everything 
appear to be private e-mail sent directly from the moderator to the 
individual recipients, you are completely changing the apparent 
nature of the communication.

	In a sense, you are lying to the recipients, giving them the 
illusion that each and every one of them is privately receiving this 
content.  Moreover, any response that they may have has a much higher 
likelihood of being something that they'd share privately but would 
not state publicly, or at least wouldn't say the same thing in the 
same way.  There would then be a serious risk that this response 
would then be shared with all the other recipients, perhaps to the 
very serious detriment of the responder.


	Fundamentally, mailing lists should not try to hide the fact that 
they exist, and that the content being sent and received is being 
shared amongst other people.

	It's fine for mailing lists to try to hide the details of their 
inner workings, perhaps to make it more difficult for people to abuse 
them inappropriately.  But they should not try to hide their very 
existence.

>  Are the specifics of what I'm suggesting clearer now?

	Nope.  It still sounds to me like you're trying to abuse the 
software for spamming.

-- 
Brad Knowles, <brad.knowles@skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

   SAGE member since 1995.  See <http://www.sage.org/> for more info.

From somuchfun at atlantismail.com  Mon May 10 14:31:00 2004
From: somuchfun at atlantismail.com (Somuchfun)
Date: Mon May 10 14:29:15 2004
Subject: suggestion for Full Customization [Mailman-Developers]
In-Reply-To: <p06002000bcc4eee70d2f@[10.0.1.2]>
Message-ID: <E1BNFWa-0004vd-4V@mail.python.org>

Brad,
I am literally shocked to see that you think everyone who does not agree
with you is a Spamer! I honestly have to question your ethics and if you
think you are better than others or just set the rules?
You might want to ignore it but there are announcement lists and newsletters
people actually want to get and this is not spam by definition. If I get a
newsletter from United Airlines for example because I am a frequent traveler
and I asked for it then it is not spam and they still use a mailing list
manager.
I have also watched this and all the other mailman lists for a while and
came to the conclusion that you have your own agenda and idea and push for
it regardless of what other people think or say.
It also seems that you tend to throw in some arrogance and all do not have a
problem to over and over throw in your "experience" to either try to out
others as beginners or "not on your level".
What James asked for is totally legitimate and has very good reasons. I have
to give him credit for being so nice after you were very rude to his simple
questions. He even offered help but you just flat out call him a spamer! How
rude!
So how "open" source is mailman really? I get more and more the impression
that mailman is the personal agenda of Brad Knowles and not a community or
group effort open to everyone who wants to help.
Let's face it - mailman has lots of shortcomings and they have not been
looked at because you personally do not feel like it. If it is a mailing
list manager like you claim then tell me how come you cannot even sort the
membership list by domain or get a clear overview of how many are suspended?
How come you cannot even edit a member entry in case someone changes their
email address?
This issues have been brought up before and you do not even comment on these
because you personally feel they are not worth your time?
Get real and come down from your "throne" and start listen to what people
really have to say and think otherwise mailman will become one day obsolete
because you were not able to see beyond your own "world".
And stop calling everyone a spamer who does not fit into your personal "box"
- I am sure you would not like me calling you a "code-nazi" either (as some
have done on other forums by the way!).

> -----Original Message-----
> From: Brad Knowles [mailto:brad.knowles@skynet.be] 
> Sent: Monday, May 10, 2004 1:51 AM
> To: James Ralston
> Cc: mailman-developers@python.org
> Subject: Re: suggestion for Full Customization [Mailman-Developers]
> 
> At 2:54 AM -0400 2004/05/10, James Ralston wrote:
> 
> >  ...why would you even *want* to have the listname for an 
> announcement
> >  list exposed in the To and/or CC header of messages sent 
> through the
> >  list?  If a recipient replies to the list, it's just going to go to
> >  the moderators, right?  In most cases, the person who is 
> sending the
> >  messages will *be* the moderator.  Why not just bypass this
> >  indirection and have the replies go directly to the sender 
> (i.e., the
> >  moderator)?
> 
> 	One of the fundamental concepts of a mailing list is 
> that people 
> know that the content is being shared with multiple recipients, and 
> anything they receive via the list is public knowledge (at least, to 
> the other list recipients), and anything they post will likewise be 
> public knowledge.  By breaking this concept and making everything 
> appear to be private e-mail sent directly from the moderator to the 
> individual recipients, you are completely changing the apparent 
> nature of the communication.
> 
> 	In a sense, you are lying to the recipients, giving them the 
> illusion that each and every one of them is privately receiving this 
> content.  Moreover, any response that they may have has a much higher 
> likelihood of being something that they'd share privately but would 
> not state publicly, or at least wouldn't say the same thing in the 
> same way.  There would then be a serious risk that this response 
> would then be shared with all the other recipients, perhaps to the 
> very serious detriment of the responder.
> 
> 
> 	Fundamentally, mailing lists should not try to hide the 
> fact that 
> they exist, and that the content being sent and received is being 
> shared amongst other people.
> 
> 	It's fine for mailing lists to try to hide the details of their 
> inner workings, perhaps to make it more difficult for people to abuse 
> them inappropriately.  But they should not try to hide their very 
> existence.
> 
> >  Are the specifics of what I'm suggesting clearer now?
> 
> 	Nope.  It still sounds to me like you're trying to abuse the 
> software for spamming.
> 
> -- 
> Brad Knowles, <brad.knowles@skynet.be>
> 
> "They that can give up essential liberty to obtain a little temporary
> safety deserve neither liberty nor safety."
>      -Benjamin Franklin, Historical Review of Pennsylvania.
> 
>    SAGE member since 1995.  See <http://www.sage.org/> for more info.
> 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Unsubscribe: 
> http://mail.python.org/mailman/options/mailman-developers/somu
> chfun%40atlantismail.com
> 


From brad.knowles at skynet.be  Mon May 10 17:27:33 2004
From: brad.knowles at skynet.be (Brad Knowles)
Date: Mon May 10 18:40:48 2004
Subject: suggestion for Full Customization [Mailman-Developers]
In-Reply-To: <E1BNFWa-0004vd-4V@mail.python.org>
References: <E1BNFWa-0004vd-4V@mail.python.org>
Message-ID: <p06002006bcc59d80cbc3@[10.0.1.2]>

At 11:31 AM -0700 2004/05/10, Somuchfun wrote:

>  You might want to ignore it but there are announcement lists and newsletters
>  people actually want to get and this is not spam by definition. If I get a
>  newsletter from United Airlines for example because I am a frequent traveler
>  and I asked for it then it is not spam and they still use a mailing list
>  manager.

	Sure, but they don't try to hide the fact that they're using a 
mailing list manager.  They don't try to make me believe that Sandra 
is sending a personal e-mail exclusively to me and no one else.

	No, they have an established business relationship with me, and 
they don't try to hide anything, except possibly how many other 
people with whom they have similar established relationships, and 
what their addresses may be.


	Trying to hide the fact that you're using a mailing list manager 
(or whatever other tool you may be using) is a typical behaviour of 
spammers, and so far as I know is not a common behaviour outside of 
that community.

	So, if you want to hide the fact that you're using a mailing list 
manager you are going to have to do a HELL of a lot of work to 
convince me that you're not a spammer.

>  I have also watched this and all the other mailman lists for a while and
>  came to the conclusion that you have your own agenda and idea and push for
>  it regardless of what other people think or say.

	You're welcome to think or claim anything you like.

>  What James asked for is totally legitimate and has very good reasons.

	Prove it.

>  Let's face it - mailman has lots of shortcomings and they have not been
>  looked at because you personally do not feel like it.

	I don't control the development on Mailman.  Barry Warsaw is the 
primary author, but code contributions are made by many people within 
the community.

>                                                        If it is a mailing
>  list manager like you claim then tell me how come you cannot even sort the
>  membership list by domain or get a clear overview of how many are suspended?
>  How come you cannot even edit a member entry in case someone changes their
>  email address?

	If you want to contribute code or otherwise be useful, you are 
welcome to do so.

>  This issues have been brought up before and you do not even comment on these
>  because you personally feel they are not worth your time?

	I haven't seen these issues being brought up on the list, and if 
they have, they're going to have to be resolved through the 
application of source code.  If you would like to help resolve these 
issues, I'm sure that Barry would be glad to take a look at whatever 
code you may wish to contribute.

>  And stop calling everyone a spamer who does not fit into your personal "box"
>  - I am sure you would not like me calling you a "code-nazi" either (as some
>  have done on other forums by the way!).

	I do not know what you have been smoking.  Whatever it is, it 
must have been some pretty damn good stuff.

	I am not Barry Warsaw.  I do not control Mailman.  I am just one 
voice on the mailing list, although I do have over a decade of 
experience building extremely large mail systems, and running large 
mailing lists.

-- 
Brad Knowles, <brad.knowles@skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

   SAGE member since 1995.  See <http://www.sage.org/> for more info.

From ssm at fnord.no  Mon May 10 19:03:42 2004
From: ssm at fnord.no (Stig Sandbeck Mathisen)
Date: Mon May 10 19:03:50 2004
Subject: suggestion for Full Customization [Mailman-Developers]
In-Reply-To: <p0600201fbcbfa6a73787@[10.0.1.2]>
References: <6F422DEF013753DE2487ED0B@pcmy.sei.cmu.edu>
	<p0600201fbcbfa6a73787@[10.0.1.2]>
Message-ID: <20040510230342.GB4591@eris.fnord.no>

On Thu, May 06, 2004 at 10:26:05AM +0200, Brad Knowles wrote:
> 	This is a mailing list.  Mailman is a mailing list manager.  It 
> is not a "hidden address so you can spam" manager.  We're not trying 
> to hide anything here, and I doubt that anyone is going to be 
> interested to see code in the mainstream package that would try to 
> address this "problem".

For announcement lists[0], being able to do handle subscriptions,
unsubscriptions and bounce handling via Mailman is a plus, since
it (in my organization) is already used for "normal" mailing lists for
internal and external use. 

Many customers, who normally only use the net for web and mail, would
prefer a mail being sent from Customer Service, and addressed to their
own address, so that they know the mail was sent to them, and that they
can hit reply to get help.

I would certainly prefer that, since a not insignificant fraction of the
users usually hits "reply to all" anyway.  This creates a lot of
unneccesary noise on the moderator interface.

Yes, that same functionality could be used to spam, but in most cases it
won't.  Mailman is simply not efficient enough for that purpose. The
spammers use hundreds of thousands of worm-infected computers today, to
spread messages.

I guess many of my problems could be solved by combining mailman
options, but I'd like a "this is an announcement list" option, that does
all this for me.

[0] Information about planned outages, unplanned outages, etc...

-- 
Stig Sandbeck Mathisen

"The key to change ... is to let go of fear"
	-- Rosanne Cash

From brad.knowles at skynet.be  Mon May 10 19:50:20 2004
From: brad.knowles at skynet.be (Brad Knowles)
Date: Mon May 10 20:10:29 2004
Subject: suggestion for Full Customization [Mailman-Developers]
In-Reply-To: <20040510230342.GB4591@eris.fnord.no>
References: <6F422DEF013753DE2487ED0B@pcmy.sei.cmu.edu>
	<p0600201fbcbfa6a73787@[10.0.1.2]>
	<20040510230342.GB4591@eris.fnord.no>
Message-ID: <p06002009bcc5c4c3ff44@[10.0.1.2]>

At 1:03 AM +0200 2004/05/11, Stig Sandbeck Mathisen wrote:

>  Many customers, who normally only use the net for web and mail, would
>  prefer a mail being sent from Customer Service, and addressed to their
>  own address, so that they know the mail was sent to them, and that they
>  can hit reply to get help.

	What do you need a mailing list manager for?  Just use a simple 
program that sends out e-mail claiming to be from your customer 
service address.  I see no need for a mailing list manager for this 
function.

>  I guess many of my problems could be solved by combining mailman
>  options, but I'd like a "this is an announcement list" option, that does
>  all this for me.

	That certainly doesn't sound like any "announcement" mailing list 
I've ever seen.

-- 
Brad Knowles, <brad.knowles@skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

   SAGE member since 1995.  See <http://www.sage.org/> for more info.

From brad.knowles at skynet.be  Tue May 11 03:57:09 2004
From: brad.knowles at skynet.be (Brad Knowles)
Date: Tue May 11 03:57:28 2004
Subject: suggestion for Full Customization [Mailman-Developers]
In-Reply-To: <20040510230342.GB4591@eris.fnord.no>
References: <6F422DEF013753DE2487ED0B@pcmy.sei.cmu.edu>
	<p0600201fbcbfa6a73787@[10.0.1.2]>
	<20040510230342.GB4591@eris.fnord.no>
Message-ID: <p06002012bcc63314eecc@[10.0.1.2]>

At 1:03 AM +0200 2004/05/11, Stig Sandbeck Mathisen wrote:

>  Many customers, who normally only use the net for web and mail, would
>  prefer a mail being sent from Customer Service, and addressed to their
>  own address, so that they know the mail was sent to them, and that they
>  can hit reply to get help.
>
>  I would certainly prefer that, since a not insignificant fraction of the
>  users usually hits "reply to all" anyway.  This creates a lot of
>  unneccesary noise on the moderator interface.

	I've been thinking about this a bit more.  The attributes you're 
asking for seem to me to be more appropriate to a Customer Relation 
Manager system, not a mailing list management system.

	Any attempt to abuse a mailing list management system (e.g., 
Mailman) into functioning like a CRM are likely to be both 
unsuccessful and painful.

	I am a strong advocate of using the right tool for the right job, 
and I'm pretty sure that Mailman is absolutely not the right tool for 
this one.


	If you (or anyone else) had any patches to bring this kind of 
functionality into Mailman, and they could be guaranteed not to 
interfere with anything else, I would still be opposed to them, but 
there would be fewer logical arguments I could make to support my 
case.

	Certainly, I would be strongly opposed to anything that would 
make it easier to abuse Mailman into a spamming tool, so you'd need 
to make sure that you addressed that issue as thoroughly as possible 
in your patches.

	If that issue was addressed, then I'd be left with arguments 
relating to code bloat and size of the community (or potential 
community) that would benefit from such patches versus the amount of 
work that would be required to keep them from suffering excessive 
"bit rot".

	However, I think my most persuasive argument would probably be 
that this would be a slippery slope and the benefited user community 
would then be even more insistent on seeing additional modifications 
made in the future to further benefit them to the potential detriment 
of the rest of the Mailman community, and the expectations that would 
be set up that could cause these two groups to become adversarial 
towards each other, with all the resulting fallout, etc....

>  Yes, that same functionality could be used to spam, but in most cases it
>  won't.  Mailman is simply not efficient enough for that purpose. The
>  spammers use hundreds of thousands of worm-infected computers today, to
>  spread messages.

	Those are the end transmission systems for the bulk of the spam 
that is sent out, yes.  But there is plenty of spam being sent out 
that does not use bot-nets.  Moreover, the spam has to be injected 
into these bot-nets, and you would have to be very careful to make 
sure that these modifications don't make it easier to abuse Mailman 
towards that end.

>  I guess many of my problems could be solved by combining mailman
>  options, but I'd like a "this is an announcement list" option, that does
>  all this for me.

	I really don't think what you're asking for is appropriate to a 
mailing list management system.  Try Googling for "customer 
relationship management system", or words to that effect.


	At the ISP I use today, and where I previously worked for two 
years, they have a simple "POP Bulletin" system to achieve these 
goals, with the messages appearing to come from Customer Service and 
all replies being sent back to them.  No mailing list management 
system involved at all -- indeed no MTAs involved, and no extra 
copies of this message stored anywhere on the server, and no 
"deliveries" of this message to individual private mailboxes.  You 
can achieve the same sorts of things with a shared IMAP folder 
system, and subscribing all users to the appropriate shared folder(s).

	If you're not an ISP and you can't use "POP Bulletin" or IMAP 
shared folder solutions, then you'd be left with traditional CRM 
systems which do actually send out real e-mail messages.

-- 
Brad Knowles, <brad.knowles@skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

   SAGE member since 1995.  See <http://www.sage.org/> for more info.

From brad.knowles at skynet.be  Tue May 11 04:46:27 2004
From: brad.knowles at skynet.be (Brad Knowles)
Date: Tue May 11 04:46:51 2004
Subject: suggestion for Full Customization [Mailman-Developers]
In-Reply-To: <20040510230342.GB4591@eris.fnord.no>
References: <6F422DEF013753DE2487ED0B@pcmy.sei.cmu.edu>
	<p0600201fbcbfa6a73787@[10.0.1.2]>
	<20040510230342.GB4591@eris.fnord.no>
Message-ID: <p06002015bcc6432db4ca@[10.0.1.2]>

At 1:03 AM +0200 2004/05/11, Stig Sandbeck Mathisen wrote:

>  Many customers, who normally only use the net for web and mail, would
>  prefer a mail being sent from Customer Service, and addressed to their
>  own address, so that they know the mail was sent to them, and that they
>  can hit reply to get help.

	For the benefit of the community, I have summarized my answer on 
this subject and put it into the Mailman FAQ at 
<http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.018.htp>.

	Please let me know if there are any other aspects of this issue 
that need to be addressed.

-- 
Brad Knowles, <brad.knowles@skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

   SAGE member since 1995.  See <http://www.sage.org/> for more info.

From stephen at xemacs.org  Tue May 11 05:13:24 2004
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue May 11 05:14:52 2004
Subject: suggestion for Full Customization [Mailman-Developers]
In-Reply-To: <E1BNFWa-0004vd-4V@mail.python.org> (somuchfun@atlantismail.com's
	message of "Mon, 10 May 2004 11:31:00 -0700")
References: <E1BNFWa-0004vd-4V@mail.python.org>
Message-ID: <87r7tr1g3v.fsf@tleepslib.sk.tsukuba.ac.jp>

>>>>> "somuchfun" == somuchfun  <somuchfun@atlantismail.com> writes:

    somuchfun> I am literally shocked to see that you think everyone
    somuchfun> who does not agree with you is a Spamer!

That's not what he said.  He said he can't think of a good reason why
a non-spammer would want to do this, while there are obvious reasons
why spammers would (and we see them do it every day).  I just think
that shows a lack of imagination on his part or maybe he just spent
too much time pushing the "Discard" button this week.

FWIW, I agree with you and James.  For an announcement list it makes
sense to me that the editor's mailbox would be placed in the From
header, and the alias for mass-mailing not be exposed at all.  I think
that would look more "professional".

Just because spammers do it too doesn't make it evil, but it is open
to abuse.  And I agree with Brad that it does change the nature of the
interaction in a way that discomfits me.  Where I differ with Brad is
that I think that's up to the list admin to deal with.  It seems to me
that James has already thought it through, and (despite Brad's
paranoia), would use the facility "responsibly" by Brad's standards.

    somuchfun> I have also watched this and all the other mailman
    somuchfun> lists for a while and came to the conclusion that you
    somuchfun> have your own agenda and idea and push for it

Yup.  That's one reason why Brad is a valuable contributor.  His ideas
are coherent, and he advocates them, backing them up with code or best
practice when appropriate.  All the top contributors do the same,
except maybe Barry, who has to worry more about balance since in the
end he makes the call.

    somuchfun> regardless of what other people think or say.

Take a deep breath ... and have some fun, will ya?



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

From brad.knowles at skynet.be  Tue May 11 05:32:23 2004
From: brad.knowles at skynet.be (Brad Knowles)
Date: Tue May 11 05:33:02 2004
Subject: suggestion for Full Customization [Mailman-Developers]
In-Reply-To: <87r7tr1g3v.fsf@tleepslib.sk.tsukuba.ac.jp>
References: <E1BNFWa-0004vd-4V@mail.python.org>
	<87r7tr1g3v.fsf@tleepslib.sk.tsukuba.ac.jp>
Message-ID: <p06002018bcc64bdfbe49@[10.0.1.2]>

At 6:13 PM +0900 2004/05/11, Stephen J. Turnbull wrote:

>  FWIW, I agree with you and James.  For an announcement list it makes
>  sense to me that the editor's mailbox would be placed in the From
>  header, and the alias for mass-mailing not be exposed at all.  I think
>  that would look more "professional".

	On further discussion (in particular the message from Stig 
Sandbeck Mathisen), I now understand that there may be valid uses for 
this sort of stuff.

	However, I do not see a valid use for them outside of the 
CRM-type of system, and I definitely believe that they have no place 
in a mailing list management system.


	Nevertheless, just because I do not see any use for this sort of 
thing in a mailing list management system, and I am opposed to this 
sort of thing being incorporated into Mailman, does not mean that you 
(and others) won't be successful in convincing Barry to accept 
patches that accomplish these goals.

	That's a discussion you're going to have to have with Barry, and 
he's going to have to take all sides of the discussions under 
advisement when he makes his decision about what sort of thing he is 
willing to incorporate.

>                                                          It seems to me
>  that James has already thought it through, and (despite Brad's
>  paranoia), would use the facility "responsibly" by Brad's standards.

	Guns can be used responsibly, and they can be used irresponsibly. 
Where most people differ is what sorts of things they believe 
can/should be done to prevent irresponsible use while not hindering 
responsible use.


	In this case, I prefer to be safe rather than sorry, and not give 
the spammers another tool to help make their job any easier than it 
already is.

	Especially since the sorts of things that people seem to want 
appear to be more appropriate to a CRM system as opposed to a mailing 
list management system, and I'm sure that many good CRM solutions 
already exist which can solve these problems much better than Mailman 
could ever hope to do.

-- 
Brad Knowles, <brad.knowles@skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

   SAGE member since 1995.  See <http://www.sage.org/> for more info.

From stephen at xemacs.org  Tue May 11 05:52:13 2004
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue May 11 05:52:27 2004
Subject: suggestion for Full Customization [Mailman-Developers]
In-Reply-To: <p06002009bcc5c4c3ff44@[10.0.1.2]> (Brad Knowles's message of
	"Tue, 11 May 2004 01:50:20 +0200")
References: <6F422DEF013753DE2487ED0B@pcmy.sei.cmu.edu>
	<p0600201fbcbfa6a73787@[10.0.1.2]>
	<20040510230342.GB4591@eris.fnord.no>
	<p06002009bcc5c4c3ff44@[10.0.1.2]>
Message-ID: <87n04f1eb6.fsf@tleepslib.sk.tsukuba.ac.jp>

>>>>> "Stig" == Stig Sandbeck Mathisen <ssm@fnord.no> wrote:

    Stig> Many customers, who normally only use the net for web and
    Stig> mail, would prefer a mail being sent from Customer Service,
    Stig> and addressed to their own address, so that they know the
    Stig> mail was sent to them, and that they can hit reply to get
    Stig> help.

>>>>> "Brad" == Brad Knowles <brad.knowles@skynet.be> writes:

    Brad> 	That certainly doesn't sound like any "announcement"
    Brad> mailing list I've ever seen.

But it accurately describes every vendor newsletter I'm subscribed to
(about 4 independent ones, some of the companies send 3 or 4, which I
hadn't counted on ;-).  They all have the editor's mailbox in From, my
address in To, no other visible addressee headers.  Some have List-*
headers, others don't.  True, mostly the editor's mailbox screams
"mass mailing", but then so does "Customer Service".

James clearly jerked your chain hard when he wrote

    I don't *WANT* the recipient to reply back to the list--or, for
    that matter, even realize that the message was sent through a
    mailing list at all.  I want the recipient to see an individual
    message that looked like it was sent *from* an individual person
    *to* an individual person.

I agree, without more context that exactly matches the spam I hate
most.  But it's very possible that the members have signed up for it
and want it that way (pastor's newsletter at their church), or didn't
sign up but would appreciate the fiction (holiday mailing to the
extended circle of family and friends).  I'm stretching, I know, but
then the stuff I'm smoking is not so good today.  :-)

And Stig describes a quite different, and very plausible, use for the
same facility.  If James is willing to do the work for it, I think
it's potentially useful, and appropriate to accept it.

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

From phma at webjockey.net  Tue May 11 07:20:48 2004
From: phma at webjockey.net (Pierre Abbat)
Date: Tue May 11 07:20:54 2004
Subject: [Mailman-Developers] Split anonymous from harvester-proof (bug
	940497)
Message-ID: <200405110720.48549.phma@webjockey.net>

I'm on a list which a few weeks ago enabled the anonymous feature to prevent a 
spammer from lurking on the list and harvesting addresses. This made it 
impossible to sort messages by sender, and several members have complained 
about this. The list is not intended to be anonymous. I propose splitting 
this feature in two:
Anonymous: Anything that looks like an email address in the headers and is not 
a message-ID is replaced with the list address. The entire From: header is 
replaced with the list address. The incoming Received: headers are deleted 
(if the sender has a static IP, they identify him).
Harvester-proof: Anything that looks like an email address in the headers and 
is not a message-ID is replaced with the list address. The rest of the From: 
header (usually the sender's name) is left alone. The Received: headers are 
left in.

phma
-- 
li fi'u vu'u fi'u fi'u du li pa

From felix.kipping at net-develop.de  Sat May 15 03:33:37 2004
From: felix.kipping at net-develop.de (Felix Kipping)
Date: Sat May 15 03:34:26 2004
Subject: [Mailman-Developers] Changing member options via command line
Message-ID: <002301c43a4e$efdb6710$fe72a8c0@Jupiter>

hello,

i have to change the member options (Mail delivery, Set Digest Mode, Get
MIME or Plain Text Digests?, Receive your own posts to the list?, Receive
acknowledgement mail when you send mail to the list?) via the command line.

i figured out that this is possible by using the withlist command and
execute a own python programm.

in the mailman faq i found the following programm to change the member
password via withlist.

---
from Mailman.Errors import NotAMemberError


def changeuserpw(mlist, addr, newpasswd):
    try:
        mlist.setMemberPassword(addr, newpasswd)
        mlist.Save()
    except NotAMemberError:
        print 'No address matched:', addr
---

i wanted to use this technique to change the above mentiones member options.
i looked into the file /Mailman/Cgi/options.py and found the function call
"setDeliveryStatus(user, newval)". i changed the programm for changing the
password into the following.

---
from Mailman.Errors import NotAMemberError


def changeuseroptions(mlist, email, delivery):
    try:
        mlist.setDeliveryStatus(email, delivery)
        mlist.Save()
    except NotAMemberError:
        print 'No address matched:', addr
----

but this causes the following error when executing.

---
Traceback (most recent call last):
  File "./withlist", line 275, in ?
    main()
  File "./withlist", line 256, in main
    r = do_list(listname, args, func)
  File "./withlist", line 189, in do_list
    return func(m, *args)
  File "./changeuseroptions.py", line 6, in changeuseroptions
    mlist.setDeliveryStatus(email, delivery)
  File
"/var/tmp/mailman-2.1.1-build/usr/lib/mailman/Mailman/OldStyleMemberships.py
", line 331, in setDeliveryStatus
AssertionError
---

does anybody know what i've done wrong and can give me a hint how i can
write
such a python programm, inorder to change the member options (Mail delivery,
Set Digest Mode, Get MIME or Plain Text Digests?, Receive your own posts to
the list?, Receive acknowledgement mail when you send mail to the list?).

or is there a python programm for download anywhere which accomplishes this
task?


Felix Kipping



From barry at python.org  Sat May 15 19:22:53 2004
From: barry at python.org (Barry Warsaw)
Date: Sat May 15 19:23:06 2004
Subject: [Mailman-Developers] RELEASED Mailman 2.1.5
Message-ID: <1084663372.1350.356.camel@anthem.wooz.org>

Today I am releasing Mailman 2.1.5, a bug fix release that also contains
new support for the Turkish language, and a few minor new features. 
Mailman 2.1.5 is a significant upgrade which should improve disk i/o
performance, administrative overhead for discarding held spams, and the
behavior of bouncing member disables.  This version also contains a fix
for an exploit that could allow 3rd parties to retrieve member
passwords.  It is thus highly recommended that all existing sites
upgrade to the latest version.

The full source tarball, as well as a patch against Mailman 2.1.4 have
been made available.  See

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

for links to downloads.

NOTE: You will want to read the UPGRADING file for important information
regarding upgrading from earlier version to Mailman 2.1.5.  A number of
internal file formats have changed so you must shut down web and mail
access to Mailman before you upgrade.  You will also want to re-run
configure (i.e. config.status) before you run "make install".

See also:

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

Finally, a personal note.  I have left Zope Corporation to join Secure
Software, a company started by John Viega -- Mailman's original author. 
Although I won't be working on Mailman in any official capacity, it is
exciting to be working with him and the rest of the folks there.  I
leave Zope Corp on a positive note and wish nothing but success for them
too.

You can find Secure Software on the web at
http://www.securesoftware.com.  Please continue to use my
barry@python.org email address for all Mailman correspondences.  I don't
expect much to change for the Mailman project at all.

Enjoy,
-Barry

2.1.5 (15-May-2004)

    - The admindb page has a checkbox that allows you to discard all held
      messages that are marked Defer.  On heavy lists with lots of spam holds,
      this makes clearing them much faster.

    - The qrunner system has changed to use only one file per message.
      However the configuration variable METADATA_FORMAT has been removed, and
      support for SAVE_MSGS_AS_PICKLES has been changed.  The latter no longer
      writes messages as plain text.  Instead, they are stored as pickles of
      plain strings, using the text pickle format.  This still makes them
      non-binary files readable and editable by humans.

      bin/dumpdb also works differently.  It will print out the entire pickle
      file (with more verbosity) and if used with 'python -i', it binds msg to
      a list of all objects found in the pickle file.

      Removed from Defaults.py: PENDINGDB_LOCK_TIMEOUT,
      PENDINGDB_LOCK_ATTEMPTS, METAFMT_MARSHAL, METAFMT_BSDDB_NATIVE,
      METAFMT_ASCII, METADATA_FORMAT

    - The bounce processor has been redesigned so that now when an address's
      bounce score reaches the threshold, that address will be sent a probe
      message.  Only if the probe bounces will the address be disabled.  The
      score is reset to zero when the probe is sent.  Also, bounce events are
      now kept in an event file instead of in memory.  This should help
      contain the bloat of the BounceRunner.

      New supporting variables in Defaults.py: VERP_PROBE_FORMAT,
      VERP_PROBE_REGEXP

      REGISTER_BOUNCES_EVERY is promoted to a Defaults.py variable.

    - The pending database has been changed from a global pickle file, to a
      unique pickle file per mailing list.

    - The 'request' database file has changed from a marshal, to the more
      secure pickle format.

    - Disallow multiple password retrievals.

    - The email package is updated to version 2.5.5.

    - New language: Turkish.

    - Bugs and patches: 869644, 869647 (NotAMemberError for old cookie data),
      878087 (bug in Slovenian catalog), 899263 (ignore duplicate pending
      ids), 810675 (discard all defers button)


From jwt at onjapan.net  Sun May 16 04:04:41 2004
From: jwt at onjapan.net (Jim Tittsler)
Date: Sun May 16 04:04:50 2004
Subject: [Mailman-Developers] Changing member options via command line
In-Reply-To: <002301c43a4e$efdb6710$fe72a8c0@Jupiter>
References: <002301c43a4e$efdb6710$fe72a8c0@Jupiter>
Message-ID: <AF66B42E-A70F-11D8-9B29-0003936A9B5C@onjapan.net>

On May 15, 2004, at 16:33, Felix Kipping wrote:

>   File
> "/var/tmp/mailman-2.1.1-build/usr/lib/mailman/Mailman/ 
> OldStyleMemberships.py
> ", line 331, in setDeliveryStatus
> AssertionError

I no longer have Mailman 2.1.1 around to check.  Which assertion is on  
line 331?

Did you remember to lock the list when invoking withlist?
Are you sure the value you are using for 'delivery' is one of the  
allowed values?
         MemberAdaptor.ENABLED,  MemberAdaptor.UNKNOWN,
         MemberAdaptor.BYUSER,   MemberAdaptor.BYADMIN,
         MemberAdaptor.BYBOUNCE

> does anybody know what i've done wrong and can give me a hint how i can
> write
> such a python programm, inorder to change the member options (Mail  
> delivery,
> Set Digest Mode, Get MIME or Plain Text Digests?, Receive your own  
> posts to
> the list?, Receive acknowledgement mail when you send mail to the  
> list?).

I posted a similar code fragment on mailman-users on May 7th for  
dealing with delivery.  For other user options, check the  
getMemberOption() and setMemberOption() functions of MemberAdaptor.


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


From barry at python.org  Sun May 16 22:53:31 2004
From: barry at python.org (Barry Warsaw)
Date: Sun May 16 22:53:43 2004
Subject: suggestion for Full Customization [Mailman-Developers]
In-Reply-To: <6F422DEF013753DE2487ED0B@pcmy.sei.cmu.edu>
References: <6F422DEF013753DE2487ED0B@pcmy.sei.cmu.edu>
Message-ID: <1084762410.19299.79.camel@anthem.wooz.org>

First off, I apologize for not having much time to interact with folks
on this list.  Hopefully I can improve that situation soon.

Rather that respond to every message in this thread, I'll try to
summarize my thoughts on this issue.  First, IMO there's little we can
do to stop spammers from using Mailman as their email engine as long as
it's covered by the GPL (which I have no intention of changing).  The
GPL cannot make prohibitions based on the use of a product, and there's
nothing from stopping some evil hackers from distributing a
spammer-patch that does some magical stuff that all spammers want.  Does
that mean we should make it easy for them?  No, of course not.  But that
also doesn't mean we should forgo useful features because we're afraid
of it being corrupted.  On the one hand, I tend to think that Mailman
just isn't the most efficient tool for spamming people, but OTOH, I do
get waves of hatemail occasionally from people who get signed up to
Mailman lists against their wishes and think I can do anything about
getting them off those lists.  Those sites usually don't stay up long
though.

Hmm, maybe I should start sneaking backdoors into the software that
dead-kills lusers who use Mailman for spamming. ;)

On CRM systems.  See the Zope Registration Manager (ZRM) at zope.com for
a system I worked on before I left ZC[1].  The mail component of that
system (only a small part of the entire system) had many similarities to
things you'll see in Mailman3, including the ability to efficiently
mail-merge information into the body of a message.  I do think that more
personal email is more user friendly email, but I am definitely
sensitive to subversion of the technology to nefarious purposes.

On this specific issue, I think there are legitimate arguments for
suppressing the addition of the posting address to the recipient
headers.  Both discussion lists and announce-only lists are within
Mailman's scope, and to the extent that including the posting address on
an announce-only list is meaningless, we should find a way to fix that. 
My biggest concern is not that it will be a subverted by spammers, but
that adding yet another option will make configuring Mailman2 lists even
more complex.  That's aside from the fact that I'm already feature-add
averse for the MM2.1 line.  OTOH, I don't see a way to tie the
reply_goes_to_list value to whether the posting address gets added to a
CC header.  They are separate things.  

A hack might be to tie this behavior to include_list_post_header.  The
intention of that variable was to suppress the RFC 2369 List-Post header
for announce-only lists, which seems the purpose here in not including
the posting address in the CC header.  Can anybody think of a reason why
you would want either the List-Post header or the posting address in a
CC header, but not both -- or neither?

-Barry

[1] This is a proprietary "visible source" product so I won't talk about
it much here.  You can contact Zope Corp for more information.  However,
my agreement with them allows me to use what I want from the Mailman
component of that for Mailman3.


From barry at python.org  Sun May 16 23:05:16 2004
From: barry at python.org (Barry Warsaw)
Date: Sun May 16 23:05:29 2004
Subject: [Mailman-Developers] Where to start Implement this?
In-Reply-To: <p06100503bcc282829868@[192.168.1.3]>
References: <p06100503bcc282829868@[192.168.1.3]>
Message-ID: <1084763116.19299.86.camel@anthem.wooz.org>

On Sat, 2004-05-08 at 09:23, Martin H?cker wrote:

> I want to create an option that allows my users to have the 
> mailinglist set a reply-to header to itself in their e-mails.

There is an unofficial patch floating around that does exactly this. 
You should check the SF patch manager for more information -- I can't
remember the details right now.

-Barry



From ricardo at rixhq.nu  Mon May 17 13:55:12 2004
From: ricardo at rixhq.nu (Ricardo)
Date: Mon May 17 13:55:19 2004
Subject: [Mailman-Developers] RELEASED Mailman 2.1.5
In-Reply-To: <1084663372.1350.356.camel@anthem.wooz.org>
References: <1084663372.1350.356.camel@anthem.wooz.org>
Message-ID: <40A8FC80.8000600@rixhq.nu>

Barry Warsaw wrote:

> NOTE: You will want to read the UPGRADING file for important information
> regarding upgrading from earlier version to Mailman 2.1.5.  A number of
> internal file formats have changed so you must shut down web and mail
> access to Mailman before you upgrade.  You will also want to re-run
> configure (i.e. config.status) before you run "make install".

First of all, thanks for releasing another update for Mailman!

But I upgraded mailman over the weekend (from 2.1.4 to 2.1.5) and only 
today I noticed that moderated messages generates errors... I think it 
has something to do with my version of python (2.1 from Debian Stable) 
not having True/False booleans by default. The weird thing is that it 
does seem to work correctly in other scripts, but ListAdmin.py generates 
an error:

May 17 19:44:25 2004 (27717) Uncaught runner exception: global name 
'True' is not defined
May 17 19:44:25 2004 (27717) Traceback (most recent call last):
   File "/usr/local/mailman/Mailman/Queue/Runner.py", line 111, in _oneloop
     self._onefile(msg, msgdata)
   File "/usr/local/mailman/Mailman/Queue/Runner.py", line 167, in _onefile
     keepqueued = self._dispose(mlist, msg, msgdata)
   File "/usr/local/mailman/Mailman/Queue/IncomingRunner.py", line 130, 
in _dispose
     more = self._dopipeline(mlist, msg, msgdata, pipeline)
   File "/usr/local/mailman/Mailman/Queue/IncomingRunner.py", line 153, 
in _dopipeline
     sys.modules[modname].process(mlist, msg, msgdata)
   File "/usr/local/mailman/Mailman/Handlers/Moderate.py", line 67, in 
process
     ModeratedMemberPost)
   File "/usr/local/mailman/Mailman/Handlers/Hold.py", line 214, in 
hold_for_approval
     id = mlist.HoldMessage(msg, reason, msgdata)
   File "/usr/local/mailman/Mailman/ListAdmin.py", line 180, in HoldMessage
     id = self.__nextid()
   File "/usr/local/mailman/Mailman/ListAdmin.py", line 113, in __nextid
     while True:
NameError: global name 'True' is not defined


I tried adding the True/False defines on top of ListAdmin.py like I saw 
in some other mailman scripts, but that doesn't seem to work... any idea 
what is going on?

TIA...


Ricardo.





From ricardo at rixhq.nu  Mon May 17 14:14:52 2004
From: ricardo at rixhq.nu (Ricardo)
Date: Mon May 17 14:14:59 2004
Subject: [Fwd: Re: [Mailman-Developers] RELEASED Mailman 2.1.5]
Message-ID: <40A9011C.6020308@rixhq.nu>


ok just talking to myself seems a bit silly :-)

-------- Original Message --------
Subject: Re: [Mailman-Developers] RELEASED Mailman 2.1.5
Date: Mon, 17 May 2004 20:05:23 +0200
From: Ricardo <ricardo@rixhq.nu>
Organization: RiXHQ
To: Ricardo <ricardo@rixhq.nu>
References: <1084663372.1350.356.camel@anthem.wooz.org> 
<40A8FC80.8000600@rixhq.nu>

> I think it
> has something to do with my version of python (2.1 from Debian Stable) 
> not having True/False booleans by default. The weird thing is that it 
> does seem to work correctly in other scripts, but ListAdmin.py generates 
> an error:
>   File "/usr/local/mailman/Mailman/ListAdmin.py", line 113, in __nextid
>     while True:
> NameError: global name 'True' is not defined
> I tried adding the True/False defines on top of ListAdmin.py like I saw 
> in some other mailman scripts, but that doesn't seem to work... any idea 
> what is going on?

I can answer my own question... after adding the defines to ListAdmin.py
  *and* stopping/starting with mailmanctl, the arrival of moderated mail
seems to work again.
I guess all the posts are losts? Well that's what I get for upgrading
without doing enough checking :(

Anyway I'll file it as a bug on sf.net

Ricardo.




From ricardo at rixhq.nu  Mon May 17 14:27:26 2004
From: ricardo at rixhq.nu (Ricardo)
Date: Mon May 17 14:27:33 2004
Subject: [Fwd: Re: [Mailman-Developers] RELEASED Mailman 2.1.5]
In-Reply-To: <40A9011C.6020308@rixhq.nu>
References: <40A9011C.6020308@rixhq.nu>
Message-ID: <40A9040E.1000505@rixhq.nu>

Ricardo wrote:

> I can answer my own question... after adding the defines to ListAdmin.py
>  *and* stopping/starting with mailmanctl, the arrival of moderated mail
> seems to work again.
> I guess all the posts are losts? Well that's what I get for upgrading
> without doing enough checking :(

I was just wondering... is it "normal" mailman behavior that in these 
kind of cases, posts don't get bounced? All the tests I sent after I 
noticed the problem disappeared into the unknown...

Ricardo.

From rmg at terc.edu  Mon May 17 14:32:19 2004
From: rmg at terc.edu (Robby Griffin)
Date: Mon May 17 14:32:27 2004
Subject: [Fwd: Re: [Mailman-Developers] RELEASED Mailman 2.1.5]
In-Reply-To: <40A9040E.1000505@rixhq.nu>
Message-ID: <87B0DE8D-A830-11D8-B54C-00039383CAAE@terc.edu>

On Monday, May 17, 2004, at 14:27 US/Eastern, Ricardo wrote:

> I was just wondering... is it "normal" mailman behavior that in these 
> kind of cases, posts don't get bounced? All the tests I sent after I 
> noticed the problem disappeared into the unknown...

Yes. Run bin/unshunt now.

	--Robby


From ricardo at rixhq.nu  Mon May 17 14:41:28 2004
From: ricardo at rixhq.nu (Ricardo)
Date: Mon May 17 14:41:35 2004
Subject: [Fwd: Re: [Mailman-Developers] RELEASED Mailman 2.1.5]
In-Reply-To: <87B0DE8D-A830-11D8-B54C-00039383CAAE@terc.edu>
References: <87B0DE8D-A830-11D8-B54C-00039383CAAE@terc.edu>
Message-ID: <40A90758.90307@rixhq.nu>

Robby Griffin wrote:

> On Monday, May 17, 2004, at 14:27 US/Eastern, Ricardo wrote:
> 
>> I was just wondering... is it "normal" mailman behavior that in these 
>> kind of cases, posts don't get bounced? All the tests I sent after I 
>> noticed the problem disappeared into the unknown...
> Yes. Run bin/unshunt now.

Thanks! You saved my day :) I was just about to send an apology to my 
list that everybody's posts were lost... luckily I didn't finish it yet.

Ricardo.

From admin.server at ntlworld.com  Mon May 17 17:20:10 2004
From: admin.server at ntlworld.com (Mark Duffy)
Date: Mon May 17 17:18:12 2004
Subject: [Mailman-Developers] Setting up mailman
Message-ID: <BFEKKDDAPHGPKFEMIFHJOEDPCAAA.admin.server@ntlworld.com>

hi there i am new to the linux server operating system and i need to
urgently set up a mailman system for a website,
i have been trying for the past week with no luck and have come to ask for
some assistance i would give remote access
so that you could configure it

if you cant could you point me to someone that can


btw is there anIRC channel for system administrators


mark
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.677 / Virus Database: 439 - Release Date: 04/05/2004


From barry at python.org  Mon May 17 22:12:49 2004
From: barry at python.org (Barry Warsaw)
Date: Mon May 17 22:13:09 2004
Subject: [Mailman-Developers] RELEASED Mailman 2.1.5
In-Reply-To: <40A8FC80.8000600@rixhq.nu>
References: <1084663372.1350.356.camel@anthem.wooz.org>
	<40A8FC80.8000600@rixhq.nu>
Message-ID: <1084846368.19299.332.camel@anthem.wooz.org>

On Mon, 2004-05-17 at 13:55, Ricardo wrote:

> But I upgraded mailman over the weekend (from 2.1.4 to 2.1.5) and only 
> today I noticed that moderated messages generates errors... I think it 
> has something to do with my version of python (2.1 from Debian Stable) 
> not having True/False booleans by default.

Dang, dang, dang.  It's getting quite untenable to continue to support
older Pythons, even in the Mailman 2.1 branch.  Given that Python 2.1
and 2.2 are no longer being supported by the PSF, I've very tempted to
require Python 2.3 for some upcoming patch version of Mailman 2.1.  How
much hardship would that impose on folks?

> I tried adding the True/False defines on top of ListAdmin.py like I saw 
> in some other mailman scripts, but that doesn't seem to work... any idea 
> what is going on?

Did you do a "mailmanctl restart" after patching that file?  I'll upload
a patch to SF, but it probably does mean a 2.1.6 isn't very far away.

-Barry



From bob at nleaudio.com  Mon May 17 23:19:04 2004
From: bob at nleaudio.com (Bob Puff@NLE)
Date: Mon May 17 23:08:09 2004
Subject: [Mailman-Developers] RELEASED Mailman 2.1.5
In-Reply-To: <1084846368.19299.332.camel@anthem.wooz.org>
References: <1084663372.1350.356.camel@anthem.wooz.org>
	<40A8FC80.8000600@rixhq.nu>
	<1084846368.19299.332.camel@anthem.wooz.org>
Message-ID: <20040518031904.M19328@nleaudio.com>


It would be a hardship over here.  Not super major, but if it's a matter of a
few simple defines, that would be a major blessing.

Bob


---------- Original Message -----------
From: Barry Warsaw <barry@python.org>
To: Ricardo <ricardo@rixhq.nu>
Sent: Mon, 17 May 2004 22:12:49 -0400
Subject: Re: [Mailman-Developers] RELEASED Mailman 2.1.5

> On Mon, 2004-05-17 at 13:55, Ricardo wrote:
> 
> > But I upgraded mailman over the weekend (from 2.1.4 to 2.1.5) and only 
> > today I noticed that moderated messages generates errors... I think it 
> > has something to do with my version of python (2.1 from Debian Stable) 
> > not having True/False booleans by default.
> 
> Dang, dang, dang.  It's getting quite untenable to continue to 
> support older Pythons, even in the Mailman 2.1 branch.  Given that 
> Python 2.1 and 2.2 are no longer being supported by the PSF, I've 
> very tempted to require Python 2.3 for some upcoming patch version 
> of Mailman 2.1.  How much hardship would that impose on folks?
> 
> > I tried adding the True/False defines on top of ListAdmin.py like I saw 
> > in some other mailman scripts, but that doesn't seem to work... any idea 
> > what is going on?
> 
> Did you do a "mailmanctl restart" after patching that file?  I'll upload
> a patch to SF, but it probably does mean a 2.1.6 isn't very far away.
> 
> -Barry
> 
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers@python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/bob%40nleaudio.com
------- End of Original Message -------


From barry at python.org  Mon May 17 23:30:14 2004
From: barry at python.org (Barry Warsaw)
Date: Mon May 17 23:30:33 2004
Subject: [Mailman-Developers] RELEASED Mailman 2.1.5
In-Reply-To: <20040518031904.M19328@nleaudio.com>
References: <1084663372.1350.356.camel@anthem.wooz.org>
	<40A8FC80.8000600@rixhq.nu>
	<1084846368.19299.332.camel@anthem.wooz.org>
	<20040518031904.M19328@nleaudio.com>
Message-ID: <1084851013.19299.338.camel@anthem.wooz.org>

On Mon, 2004-05-17 at 23:19, Bob Puff@NLE wrote:
> It would be a hardship over here.  Not super major, but if it's a matter of a
> few simple defines, that would be a major blessing.

Thanks for the data point.

-Barry



From ricardo at rixhq.nu  Tue May 18 02:28:05 2004
From: ricardo at rixhq.nu (Ricardo)
Date: Tue May 18 02:28:11 2004
Subject: [Mailman-Developers] RELEASED Mailman 2.1.5
In-Reply-To: <1084846368.19299.332.camel@anthem.wooz.org>
References: <1084663372.1350.356.camel@anthem.wooz.org>	<40A8FC80.8000600@rixhq.nu>
	<1084846368.19299.332.camel@anthem.wooz.org>
Message-ID: <40A9ACF5.1040301@rixhq.nu>

Barry Warsaw wrote:

>>But I upgraded mailman over the weekend (from 2.1.4 to 2.1.5) and only 
>>today I noticed that moderated messages generates errors... I think it 
>>has something to do with my version of python (2.1 from Debian Stable) 
>>not having True/False booleans by default.
> Dang, dang, dang.  It's getting quite untenable to continue to support
> older Pythons, even in the Mailman 2.1 branch.  Given that Python 2.1
> and 2.2 are no longer being supported by the PSF, I've very tempted to
> require Python 2.3 for some upcoming patch version of Mailman 2.1.  How
> much hardship would that impose on folks?

Well, Debian stable doesn't go beyond python2.2, so that would mean 
Debian users will either need to install python from source or find a 
backport. It'll take a while before the new stable Debian is released. I 
don't now the state of other distro's.
In my case installing from source would be an option, but I'm not a big 
fan of it.
But what I was thinking, does it really have to be defined seperatedly 
in every python file which uses it? I'd think there should be a way in 
python to define it in just one place.

Ricardo.

From jerry at sandiego.edu  Tue May 18 13:09:23 2004
From: jerry at sandiego.edu (Jerold Stratton)
Date: Tue May 18 13:09:32 2004
Subject: [Mailman-Developers] RELEASED Mailman 2.1.5
In-Reply-To: <40A9ACF5.1040301@rixhq.nu>
Message-ID: <1BEBB354-A8EE-11D8-81FA-000A959F54EC@sandiego.edu>

On Monday, May 17, 2004, at 11:28  PM, Ricardo wrote:
> Well, Debian stable doesn't go beyond python2.2, so that would mean 
> Debian users will either need to install python from source or find a 
> backport. It'll take a while before the new stable Debian is released. 
> I don't now the state of other distro's.
> In my case installing from source would be an option, but I'm not a 
> big fan of it.
>

Mac OS X 10.3 has Python 2.3, but Mac OS X 10.2 has 2.2; our web server 
has 10.2 and is likely to stay that way for about one more year. (Apple 
continues to support Mac OS X 10.2 and 10.2 Server with security 
updates.) Given current time constraints and lack of desire to track 
down dependencies, I probably would not perform any mailman upgrade 
that also required a python upgrade unless the python upgrade was 
*exceedingly* simple and did not require *any other* software or 
libraries to change; it was "interesting" enough getting mailman to 
work across two different platforms--the web portion and the mail 
portion are on Mac OS X and a very old Solaris, respectively.

On the other hand, I'm pushing for an integrated solution in which 
mailman's mail server and web server are both on the same machine, in 
which case this would no longer be a problem.

So in our case, it most likely will be an issue for about another year.

Jerry
jerry@sandiego.edu
http://www.sandiego.edu/~jerry/
Serra 188B/x8773
--
"The major difference between a thing that might go wrong and a thing 
that cannot possibly go wrong is that when a thing that cannot possibly 
go wrong goes wrong it usually turns out to be impossible to get at and 
repair."--Douglas Adams (Mostly Harmless)


From jdennis at redhat.com  Tue May 18 14:44:53 2004
From: jdennis at redhat.com (John Dennis)
Date: Tue May 18 14:45:01 2004
Subject: [Mailman-Developers] Re: [Mailman-Announce] RELEASED Mailman 2.1.5
In-Reply-To: <1084663372.1350.356.camel@anthem.wooz.org>
References: <1084663372.1350.356.camel@anthem.wooz.org>
Message-ID: <1084905893.24581.326.camel@finch.boston.redhat.com>

On Sat, 2004-05-15 at 19:22, Barry Warsaw wrote:
> This version also contains a fix
> for an exploit that could allow 3rd parties to retrieve member
> passwords.  It is thus highly recommended that all existing sites
> upgrade to the latest version.

Could you be more specific about the exploit? Is there a CVE or CAN open
against it? I assume given the public announcement this is not an
embargoed security exploit, or is it?

-- 
John Dennis <jdennis@redhat.com>


From tkikuchi at is.kochi-u.ac.jp  Tue May 18 22:17:52 2004
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Tue May 18 22:18:16 2004
Subject: [Mailman-Developers] Re: [Mailman-Announce] RELEASED Mailman 2.1.5
In-Reply-To: <1084905893.24581.326.camel@finch.boston.redhat.com>
References: <1084663372.1350.356.camel@anthem.wooz.org>
	<1084905893.24581.326.camel@finch.boston.redhat.com>
Message-ID: <40AAC3D0.9010707@is.kochi-u.ac.jp>

Hi John and Hi Barry.

John Dennis wrote:

> On Sat, 2004-05-15 at 19:22, Barry Warsaw wrote:
> 
>>This version also contains a fix
>>for an exploit that could allow 3rd parties to retrieve member
>>passwords.  It is thus highly recommended that all existing sites
>>upgrade to the latest version.
> 
> 
> Could you be more specific about the exploit? Is there a CVE or CAN open
> against it? I assume given the public announcement this is not an
> embargoed security exploit, or is it?
> 

The exploit is very easy for anyone who can view the source (and diff)
with curiosity. So, we should send CVE/CAN ASAP, I think.


-- 
Tokio


From John.Leo at YMCA.NET  Wed May 19 12:11:26 2004
From: John.Leo at YMCA.NET (Leo, John)
Date: Wed May 19 12:11:32 2004
Subject: [Mailman-Developers] archive redirect
Message-ID: <26F6CD04E7BCA4459EB2674CC8A21991398045@exymca04.YMCA.NET>

We upgraded to 2.1.5 and the links to all our archives changed to our
Outlook web URL/pipermail/listname. Has anyone seen this?

 

John Leo

Manager, Application Development

YMCA of the USA

312-419-8938

At the YMCA, we build strong kids, strong families and strong
communities

Find any YMCA in the USA at www.ymca.net

 

 

From anarcat at anarcat.ath.cx  Wed May 19 12:11:31 2004
From: anarcat at anarcat.ath.cx (The Anarcat)
Date: Wed May 19 12:11:39 2004
Subject: [Mailman-Developers] Re: RELEASED Mailman 2.1.5
In-Reply-To: <20040519160024.B1D33126@shall.anarcat.ath.cx>
References: <20040519160024.B1D33126@shall.anarcat.ath.cx>
Message-ID: <40AB8733.5010801@anarcat.ath.cx>

> On Sat, 2004-05-15 at 19:22, Barry Warsaw wrote:
> 
>>This version also contains a fix
>>for an exploit that could allow 3rd parties to retrieve member
>>passwords.  It is thus highly recommended that all existing sites
>>upgrade to the latest version.
> 
> Could you be more specific about the exploit? Is there a CVE or CAN open
> against it? I assume given the public announcement this is not an
> embargoed security exploit, or is it?

Also: what versions of mailman are affected?

A.

From admin.server at ntlworld.com  Wed May 19 13:09:46 2004
From: admin.server at ntlworld.com (Mark Duffy)
Date: Wed May 19 13:07:49 2004
Subject: [Mailman-Developers] Mailman IRC room
Message-ID: <BFEKKDDAPHGPKFEMIFHJCEFHCAAA.admin.server@ntlworld.com>

are there any other IRC rooms other than #mailman on freenode

mark
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.677 / Virus Database: 439 - Release Date: 04/05/2004


From wheakory at isu.edu  Wed May 19 14:14:42 2004
From: wheakory at isu.edu (Kory Wheatley)
Date: Wed May 19 14:19:39 2004
Subject: [Mailman-Developers] Global Pipeline question
Message-ID: <40ABA412.7050005@isu.edu>

I'm currently using Mailman 2.1.4 with Postfix on a Red Hat Enterprise 
Verison 3 workstation.

I would like to use the scrubber.patch to put attachments has a viewable 
link in the archives, "which is working", but I also want the attachment 
completely stripped from the email message.  Here's my problem, if I 
enable content filtering to strip the attachments, scrubber never puts 
the attachment as a link in the archives.  I thought it might be a 
Global Pipeline issue, so
I changed the sequence of the global pipeline "as shown below", and put 
Scrubber as the first Handler to be processed and of course put this in 
"mm_cfg.py" and restarted Mailman.  Still,  the content filtering strips 
the attachments like I want, but  scrubber never puts the attachment as 
a link in the archives.

Does the sequence of the Pipeline affect this process, is there a way to 
do what I want?  Also is there documentation that shows a step by step 
process that a message goes through before delivery?  I would love to 
see this, it would help me understand the process that Mailman does to 
prepare a message for delivery.

I manage 200 lists at Idaho State Univeristy, and Mailman is a very 
critical application for us, which makes this task very important and in 
a rush to get accomplished.

I would appreciate your help.

GLOBAL_PIPELINE = [
    # These are the modules that do tasks common to all delivery paths.
    'Scrubber',
    'SpamDetect',
    'Approve',
    'Replybot',
    'Moderate',
    'Hold',
    'MimeDel',
    'Emergency',
    'Tagger',
    'CalcRecips',
    'AvoidDuplicates',
    'Cleanse',
    'CookHeaders',
# And now we send the message to the digest mbox file, and to the arch and
    # news queues.  Runners will provide further processing of the message,
    # specific to those delivery paths.
    'ToDigest',
    'ToArchive',
    'ToUsenet',
    # Now we'll do a few extra things specific to the member delivery
    # (outgoing) path, finally leaving the message in the outgoing queue.
    'AfterDelivery',
    'Acknowledge',
    'ToOutgoing',
    ]

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


From fil at rezo.net  Wed May 19 16:36:07 2004
From: fil at rezo.net (Fil)
Date: Wed May 19 16:35:46 2004
Subject: [Mailman-Developers] trad-lang
Message-ID: <20040519203607.GB14067@rezo.net>

Hi,

a while ago we talked about the translation script we develop and use for
SPIP (www.spip.net); there was some interest on this list, so here's a small
update:

trad-lang now has its own webpage, at http://eledo.com/download/trad_lang

but the best news is that there's a demo:
http://www.eledo.com/demo-trad-lang/trad-lang/trad_lang.php

log in as demo/demodemo

The next release will be able to export files in any format (.po among
others).

-- Fil


From mailmandev at waikato.ac.nz  Wed May 19 17:16:54 2004
From: mailmandev at waikato.ac.nz (Colin Palmer)
Date: Wed May 19 17:16:59 2004
Subject: removing arbitrary headers [Mailman-Developers]
In-Reply-To: <26260000.1083111839@pcmy.sei.cmu.edu>
References: <40704E69.6515.D517F5@localhost> <40705791.29902.F8D978@localhost>
	<14E3383C-8662-11D8-8B76-0003934516A8@plaidworks.com>
	<26260000.1083111839@pcmy.sei.cmu.edu>
Message-ID: <1085001414.21277.119.camel@firefox.cc.waikato.ac.nz>

On Wed, 2004-04-28 at 12:23, James Ralston wrote:
> On 2004-04-04 at 11:01:22-07 Chuq Von Rospach <chuqui@plaidworks.com> wrote:
> > I definitely see it as useful to be able to strip out headers that
> > cause systems to auto-reply with a return receipt.
> IMHO, this statement can be shortened to "I definitely think it would
> be useful to strip out arbitrary headers."

I agree too, so here's a patch for my first attempt at it:

https://sourceforge.net/tracker/index.php?func=detail&aid=957054&group_id=103&atid=300103

-- 
Colin Palmer <mailmandev@waikato.ac.nz>
University of Waikato


From lloyd_tennison at whoever.com  Thu May 20 05:10:17 2004
From: lloyd_tennison at whoever.com (Lloyd Tennison)
Date: Thu May 20 05:10:12 2004
Subject: [Mailman-Developers] Re: [ mailman-Patches-957054 ] Strip arbitrary
	headers from postsbefore delivery
Message-ID: <PC167020040520021017047433e28b8b@main>

Can't anyone spell "Receipt?"(I before E except after C!) 

For it to really work it needs to be spelled correctly.

>Patches item #957054, was opened at 2004-05-20 09:07
>Message generated for change (Comment added) made by tzs
>You can respond by visiting: 
>https://sourceforge.net/tracker/?func=detail&atid=300103&aid=957054&group_id=103
>
>Category: mail delivery
>Group: Mailman 2.1
>Status: Open
>Resolution: None
>Priority: 5
>Submitted By: Colin Palmer (tzs)
>Assigned to: Nobody/Anonymous (nobody)
>Summary: Strip arbitrary headers from posts before delivery
>
>Initial Comment:
>This patch adds an extra config option under Privacy
>Options... / Header Munging that lets the list admin
>specify arbitrary headers to be removed by CookHeaders.
>
>----------------------------------------------------------------------
>
>>Comment By: Colin Palmer (tzs)
>Date: 2004-05-20 14:41
>
>Message:
>Logged In: YES 
>user_id=658762
>
>This version should work a little better.
>Warning: messes with Defaults.py and versions.py and could
>cause nasty things to happen to any existing mailing list
>you have.
>
>----------------------------------------------------------------------
>
>You can respond by visiting: 
>https://sourceforge.net/tracker/?func=detail&atid=300103&aid=957054&group_id=103
>
>_______________________________________________
>Mailman-coders mailing list
>Mailman-coders@python.org
>http://mail.python.org/mailman/listinfo/mailman-coders
>


From Daniel.Buchmann at bibsys.no  Thu May 20 06:22:24 2004
From: Daniel.Buchmann at bibsys.no (Daniel Buchmann)
Date: Thu May 20 06:22:30 2004
Subject: [Mailman-Developers] Python versions (was: Re: RELEASED Mailman
	2.1.5)
In-Reply-To: <40A9ACF5.1040301@rixhq.nu>
References: <1084663372.1350.356.camel@anthem.wooz.org>
	<40A8FC80.8000600@rixhq.nu>
	<1084846368.19299.332.camel@anthem.wooz.org>
	<40A9ACF5.1040301@rixhq.nu>
Message-ID: <1085048544.2692.180.camel@fornax.hjemme.bibsys.no>

On Tue, 2004-05-18 at 08:28, Ricardo wrote:
> > Dang, dang, dang.  It's getting quite untenable to continue to support
> > older Pythons, even in the Mailman 2.1 branch.  Given that Python 2.1
> > and 2.2 are no longer being supported by the PSF, I've very tempted to
> > require Python 2.3 for some upcoming patch version of Mailman 2.1.  How
> > much hardship would that impose on folks?
> 
> Well, Debian stable doesn't go beyond python2.2, so that would mean 
> Debian users will either need to install python from source or find a 
> backport. It'll take a while before the new stable Debian is released. I 
> don't now the state of other distro's.

Here's a summary of Python versions on other popular distro's:

RedHat:
  RedHat 8.0 has Python 2.2.1
  RedHat 9.0 has Python 2.2.2
  Fedora Core 1 has Python 2.2.3

Mandrake:
  Mandrake Linux 9.2 has Python 2.3
  Mandrake Linux 10.0 has Python 2.3.3

Gentoo supports these Python versions:
	2.3.1-r1, 2.2.2, 2.2.3-r5. 2.3.3, 2.3.3-r1, 2.3.4_rc1


Looks like RedHat users will have to build Python from source if 2.3
becomes a requirement...
:)


-Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20040520/1d572d15/attachment.bin
From brad.knowles at skynet.be  Thu May 20 08:35:20 2004
From: brad.knowles at skynet.be (Brad Knowles)
Date: Thu May 20 08:36:22 2004
Subject: [Mailman-Developers] Python versions (was: Re:
	RELEASED Mailman 	2.1.5)
In-Reply-To: <1085048544.2692.180.camel@fornax.hjemme.bibsys.no>
References: <1084663372.1350.356.camel@anthem.wooz.org>
	<40A8FC80.8000600@rixhq.nu>
	<1084846368.19299.332.camel@anthem.wooz.org>
	<40A9ACF5.1040301@rixhq.nu>
	<1085048544.2692.180.camel@fornax.hjemme.bibsys.no>
Message-ID: <p0600200cbcd2565c5fba@[10.0.1.3]>

At 12:22 PM +0200 2004/05/20, Daniel Buchmann wrote:

>  Looks like RedHat users will have to build Python from source if 2.3
>  becomes a requirement...
>  :)

	Looks like this problem is already becoming a frequent question 
on mailman-users.  We should put something into the FAQ to address 
this, or fix the code to suit.

-- 
Brad Knowles, <brad.knowles@skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

   SAGE member since 1995.  See <http://www.sage.org/> for more info.

From brad.knowles at skynet.be  Thu May 20 08:49:52 2004
From: brad.knowles at skynet.be (Brad Knowles)
Date: Thu May 20 08:50:19 2004
Subject: [Mailman-Developers] Re: [Mailman-Users] Moderated mailing list not
	working...
In-Reply-To: <p0600200abcd251e3537e@[10.0.1.3]>
References: <047901c43e5c$edca54b0$d724b242@sitedomain.local>
	<p0600200abcd251e3537e@[10.0.1.3]>
Message-ID: <p0600200dbcd259ac26a3@[10.0.1.3]>

At 2:17 PM +0200 2004/05/20, Brad Knowles wrote:

>  	From the "NameError: global name 'True' is not defined" error at the
>  bottom, I have to wonder what version of Mailman you have installed, and
>  what version of Python you are using.  If you search the archives, you
>  will see that some older versions of Python apparently don't have
>  "True" predefined, which can cause problems with newer versions of
>  Mailman.

	Actually, I decided to go ahead and put this issue into the FAQ. 
See 
<http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.042.htp>.

-- 
Brad Knowles, <brad.knowles@skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

   SAGE member since 1995.  See <http://www.sage.org/> for more info.

From jdennis at redhat.com  Thu May 20 13:45:57 2004
From: jdennis at redhat.com (John Dennis)
Date: Thu May 20 13:46:04 2004
Subject: [Mailman-Developers] Python versions (was: Re: RELEASED
	Mailman 2.1.5)
In-Reply-To: <1085048544.2692.180.camel@fornax.hjemme.bibsys.no>
References: <1084663372.1350.356.camel@anthem.wooz.org>
	<40A8FC80.8000600@rixhq.nu>
	<1084846368.19299.332.camel@anthem.wooz.org>
	<40A9ACF5.1040301@rixhq.nu>
	<1085048544.2692.180.camel@fornax.hjemme.bibsys.no>
Message-ID: <1085075157.3867.137.camel@finch.boston.redhat.com>

On Thu, 2004-05-20 at 06:22, Daniel Buchmann wrote:
> Here's a summary of Python versions on other popular distro's:
> 
> RedHat:
>   RedHat 8.0 has Python 2.2.1
>   RedHat 9.0 has Python 2.2.2
>   Fedora Core 1 has Python 2.2.3

> Looks like RedHat users will have to build Python from source if 2.3
> becomes a requirement...

FC2 which was just released has 2.3.3 as will RHEL4. Red Hat users if
they use Red Hat rpms will never have to build Python from source.

-- 
John Dennis <jdennis@redhat.com>


From carson at taltos.org  Thu May 20 14:01:24 2004
From: carson at taltos.org (Carson Gaspar)
Date: Thu May 20 14:01:30 2004
Subject: [Mailman-Developers] Python versions (was: Re: RELEASED	Mailman
	2.1.5)
In-Reply-To: <1085075157.3867.137.camel@finch.boston.redhat.com>
References: <1084663372.1350.356.camel@anthem.wooz.org>
	<40A8FC80.8000600@rixhq.nu>	<1084846368.19299.332.camel@anthem.wooz.org>
	<40A9ACF5.1040301@rixhq.nu>
	<1085048544.2692.180.camel@fornax.hjemme.bibsys.no>
	<1085075157.3867.137.camel@finch.boston.redhat.com>
Message-ID: <F7EF8E8455A81C3E366FADC9@taltos.ny.ficc.gs.com>

--On Thursday, May 20, 2004 13:45:57 -0400 John Dennis <jdennis@redhat.com> 
wrote:

> FC2 which was just released has 2.3.3 as will RHEL4. Red Hat users if
> they use Red Hat rpms will never have to build Python from source.

Speaking as a RHEL 3.0 (3.1 Real Soon Now - maybe this one will work!) 
customer, I seriously doubt we'll be on RHEL 4 any time soon (or did Red 
Hat do a better job of getting ISVs on board this time?). Of course, we 
don't run mailman (that I know of), and if we did, compiling python would 
be no trouble at all.

-- 
Carson


From miranda at uranus.com  Thu May 20 23:43:13 2004
From: miranda at uranus.com (Michael Chang)
Date: Thu May 20 23:44:04 2004
Subject: [Mailman-Developers] Bindings, preferences, storage engines, oh my!
Message-ID: <Pine.LNX.4.44.0405202323060.23895-100000@ion.uranus.com>


The title says it all, no?

Folks,

I've peeked and poked around the mailing-list archives as well as the Zope 
Wiki, and I haven't yet seen anything that substantially fulfills what I'm 
looking for.  I've been using Mailman for a few years now, and as far as 
a mailing-list engine, it's great stuff.  However, when the time came for 
me to integrate it with other pieces of software, it left me high and dry.

The abbreviated version of what I need to do is this: write my own 
adminitrative front-end for global, per-list and per-user preferences; be 
able to store said preferences in an LDAP server.

I think it would be great to be able to access all of the preferences 
through any one of a number of common languages (Perl, C, C++, Java).  
That way, people could use the language that they feel most comfortable 
using.
As well, it would be a boon to be able to store and retrieve 
preference data in any format that one might choose (or choose to 
implement).

In order for both of the above to work, Mailman is going to need to access 
said preference data through plug-ins which sit atop a generic, "virtual
data preferences" layer which can access the preference data in an
administrator-defined way.  Upon installation, the administrator
will edit a configuration file that defines how the virtual preferences
will talk to the plug-ins -- essentially, the configuration file glues
the "virtual" to the "real."  The "real" can be anything from named
pipes to sockets to shared libraries to native Python classes.  Both
the Mailman engine itself and the out-of-the-box command-line utilities
that come with it will rely upon said glue file in order to access global-,
list-, and user-preference information.

 +--------------------------+
 |   preference modules*    |    (3)
 ---------------------------- ^
 [ configuration directives ] ^  (2)
 +--------------------------+ ^
 |  generic/virtual prefs   | ^  (1)
 +--------------------------+

1.) maintained by the Mailman developers

2.) a configuration file (possibly in XML format) that maps the
    generic methods (by name, I suppose) to preference modules.
	If the preference module is code, then just map the MemberAdaptor
	method names to get/set methods supported by the preference module.

3.) can be a socket, pipe, shared library, Python class, etc.  (Can Python
    bootstrap .so libs and call the functions within them?  Also, can
	Python talk to Perl scripts or Java bytecode?)


I think that once the above is taken care of, the storage method will
be a moot point, since there exist numerous libraries with numerous
language bindings for BerkeleyDB, various SQL servers, LDAP servers,
etc.

Putting the two together will allow people to be able to write their
own front-ends; additionally, it will relieve the Mailman developers
of having to develop and maintain any storage and retrieval code -- they'd
only have to take care of the virtual layer.  I suppose it would be like
Apache modules are to the Apache server, or how SNMP modules are to
the net-snmp suite where one can bind an OID to a shell script, a Perl
script, a C library, etc.

While I'd be willing to write my own preferences backend for the current
Mailman as it is, I'd be worried about the code changing from underneath
me within the next x release(s), thus forcing me to modify code just
to get things working again.

Any thoughts?  Has any work gone into this sort of thing yet?  Is there
any room in Mailman's plumbing to fit such a virtual preferences layer?


Michael



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


From kl at vsen.dk  Fri May 21 17:19:01 2004
From: kl at vsen.dk (Klavs Klavsen)
Date: Fri May 21 17:19:07 2004
Subject: [Mailman-Developers] bug in 2.1.5 - danish translation - can't
	unsubscribe
Message-ID: <34907.10.0.0.51.1085174341.squirrel@www.enableit.dk>

Hi guys,

When viewing the user page in danish (with 30% or less translated - I'll
have a look a that at some point when I get the time) - it fails with this
message (it works fine when using english):

Bug in Mailman version 2.1.5

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



Python information:

Variable	Value
sys.version	2.2.3 (#1, Jul 28 2003, 11:43:19) [GCC 3.2.2 20030322 (Gentoo
Linux 1.4 3.2.2-r2)]
sys.executable	/usr/bin/python
sys.prefix	/usr
sys.exec_prefix	/usr
sys.path	/usr
sys.platform	linux2

Environment variables:

Variable	Value
PATH_INFO 	/lp-nyhedsbrev
CONTENT_LENGTH 	100
CONTENT_TYPE 	application/x-www-form-urlencoded
HTTP_COOKIE 	POSTNUKESID=5241e6345df9c0303def0d4b0749ea3a
SCRIPT_FILENAME 	/usr/local/mailman/cgi-bin/options
PYTHONPATH 	/usr/local/mailman
SERVER_SOFTWARE 	Apache
SERVER_ADMIN 	admin@EnableIT.dk
SCRIPT_NAME 	/mailman/options
SCRIPT_URI 	http://www.mysite.dk/mailman/options/lp-nyhedsbrev
SERVER_SIGNATURE
REQUEST_METHOD 	POST
HTTP_HOST 	www.mysite.dk
SCRIPT_URL 	/mailman/options/lp-nyhedsbrev
SERVER_PROTOCOL 	HTTP/1.1
QUERY_STRING
REQUEST_URI 	/mailman/options/lp-nyhedsbrev
HTTP_ACCEPT
	text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
HTTP_ACCEPT_CHARSET 	ISO-8859-1,utf-8;q=0.7,*;q=0.7
HTTP_USER_AGENT 	Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6)
Gecko/20040418 Firefox/0.8
HTTP_CONNECTION 	keep-alive
HTTP_REFERER 	http://www.mysite.dk/mailman/listinfo/lp-nyhedsbrev
SERVER_NAME 	my site
REMOTE_ADDR 	<client-ip-removed>
HTTP_KEEP_ALIVE 	300
REMOTE_PORT 	34514
HTTP_ACCEPT_LANGUAGE 	en-us,en;q=0.5
PATH_TRANSLATED 	/www/websites/mysite/html/lp-nyhedsbrev
SERVER_PORT 	80
GATEWAY_INTERFACE 	CGI/1.1
HTTP_ACCEPT_ENCODING 	gzip,deflate
SERVER_ADDR 	192.168.1.2
DOCUMENT_ROOT 	/www/websites


-- 
Regards,
Klavs Klavsen, GSEC - kl@vsen.dk - http://www.vsen.dk
PGP: 7E063C62/2873 188C 968E 600D D8F8  B8DA 3D3A 0B79 7E06 3C62

"Those who do not understand Unix are condemned to reinvent it, poorly."
  --Henry Spencer

From tkikuchi at is.kochi-u.ac.jp  Fri May 21 20:58:34 2004
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Fri May 21 20:58:56 2004
Subject: [Mailman-Developers] Global Pipeline question
In-Reply-To: <40ABA412.7050005@isu.edu>
References: <40ABA412.7050005@isu.edu>
Message-ID: <40AEA5BA.2020905@is.kochi-u.ac.jp>


> 
> GLOBAL_PIPELINE = [
>    # These are the modules that do tasks common to all delivery paths.
>    'Scrubber',
>    'SpamDetect',
>    'Approve',

Putting 'Scrubber' first in the pipeline is not cleaver because 
attachments from spam and virus may be archived.

-- 
Tokio


From somuchfun at atlantismail.com  Sat May 22 00:03:25 2004
From: somuchfun at atlantismail.com (Somuchfun)
Date: Sat May 22 00:03:52 2004
Subject: [Mailman-Developers] Question for clarification about bounce
	management
Message-ID: <mailman.92.1085198632.6944.mailman-developers@python.org>

Can one of the mailman pros on the list enlighten me about how the bounce
management works in the background?
Let's say the list is set to suspend a member after 3 bounces and then
delete him after 3 more attempts, each 7 days apart. So lets say one member
has had 3 bounces and is suspended. Now suddenly I change the list settings
so it requires 5 bounces before a member is suspended. Will the list notice
this during the next time it sends out emails? How does the list check the
current settings of the list versus the individual status? Is there a
cleanup process for members who are dormant because of changes in the list
settings?

Thanks for all the input on this!


From Nigel.Metheringham at dev.InTechnology.co.uk  Fri May 21 04:57:18 2004
From: Nigel.Metheringham at dev.InTechnology.co.uk (Nigel Metheringham)
Date: Sat May 22 07:44:32 2004
Subject: [Mailman-Developers] Python versions (was: Re: RELEASED
	Mailman 2.1.5)
In-Reply-To: <1085075157.3867.137.camel@finch.boston.redhat.com>
References: <1084663372.1350.356.camel@anthem.wooz.org>
	<40A8FC80.8000600@rixhq.nu>
	<1084846368.19299.332.camel@anthem.wooz.org>
	<40A9ACF5.1040301@rixhq.nu>
	<1085048544.2692.180.camel@fornax.hjemme.bibsys.no>
	<1085075157.3867.137.camel@finch.boston.redhat.com>
Message-ID: <1085129838.9078.18.camel@angua.localnet>

On Thu, 2004-05-20 at 18:45, John Dennis wrote:
> FC2 which was just released has 2.3.3 as will RHEL4. Red Hat users if
> they use Red Hat rpms will never have to build Python from source.

Don't expect people to be running the current release all the time or to
hold off mailman updates until OS refreshes.

Many of the mailman updates within 2.1 have been security related
updates, but now appear to be mandate underlying package updates that do
not have security related problems.  Python 2.3 is also less than a year
from release so forcing its requirement for packages that are undergoing
minor release updates appears to me to be premature.

Personally I'd argue for continuing to support Python 2.2 in the 2.1
series.  If this is really impracticable then we should make sure the
installer picks up the python version and refuses to install without
major threats and bludgeoning if the local python is not up to scratch.

	Nigel.
-- 
[ Nigel Metheringham           Nigel.Metheringham@InTechnology.co.uk ]
[ - Comments in this message are my own and not ITO opinion/policy - ]


From stephen at xemacs.org  Sat May 22 08:40:47 2004
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat May 22 08:40:56 2004
Subject: [Mailman-Developers] Python versions
In-Reply-To: <1085048544.2692.180.camel@fornax.hjemme.bibsys.no> (Daniel
	Buchmann's message of "Thu, 20 May 2004 12:22:24 +0200")
References: <1084663372.1350.356.camel@anthem.wooz.org>
	<40A8FC80.8000600@rixhq.nu>
	<1084846368.19299.332.camel@anthem.wooz.org>
	<40A9ACF5.1040301@rixhq.nu>
	<1085048544.2692.180.camel@fornax.hjemme.bibsys.no>
Message-ID: <87fz9s8wj4.fsf@tleepslib.sk.tsukuba.ac.jp>

>>>>> "Daniel" == Daniel Buchmann <Daniel.Buchmann@bibsys.no> writes:

    Daniel> Here's a summary of Python versions on other popular
    Daniel> distro's:

[Linux reports elided]

On Mac OS X 10.3 (aka Panther), we have

    Apple -> 2.3

IIRC Mac OS X 10.2 (aka Jaguar) was Python 2.1.  On the third-party
ditribution front:

    Fink -> 2.3.3
    DarwinPorts -> 2.3.3

by default.  As far as I can tell from the config files in both cases
2.3 would be the default on earlier versions of Mac OS X as well (Fink
has different distributions for 10.2 and 10.3, AFAIK DarwinPorts does
not).  I'll let somebody else judge whether the population at risk of
inconvenience from requiring Python 2.3 is large enough to worry about.

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

From rmg at datadomain.com  Mon May 24 21:56:20 2004
From: rmg at datadomain.com (Rich Geiger)
Date: Mon May 24 21:56:25 2004
Subject: [Mailman-Developers] Bug in Utils.py funtction ScriptURL()?
Message-ID: <200405250156.i4P1uKb14861@rmg.datadomain.com>


> def ScriptURL(target, web_page_url=None, absolute=False):
>     """target - scriptname only, nothing extra
>     web_page_url - the list's configvar of the same name
>     absolute - a flag which if set, generates an absolute url
>     """
>     if web_page_url is None:
>         web_page_url = mm_cfg.DEFAULT_URL_PATTERN % get_domain()
>         if web_page_url[-1] <> '/':
>             web_page_url = web_page_url + '/'
>     fullpath = os.environ.get('REQUEST_URI')
>     if fullpath is None:
>         fullpath = os.environ.get('SCRIPT_NAME', '') + \
>                    os.environ.get('PATH_INFO', '')
>     baseurl = urlparse.urlparse(web_page_url)[2]
>     if not absolute and fullpath.endswith(baseurl):
                                   ^^^^^^^^^^^^^^^^^
>         # Use relative addressing
>         fullpath = fullpath[len(baseurl):]
>         i = fullpath.find('?')
>         if i > 0:
>             count = fullpath.count('/', 0, i)
>         else:
>             count = fullpath.count('/')
>         path = ('../' * count) + target
>     else:
>         path = web_page_url + target
>     return path + mm_cfg.CGIEXT
> 

I'm curious about the "if not absolute ..." test in the code above.
Is it possible that the author really wanted 

      if not absolute and fullpath.startswith(baseurl):
                                   
?

This would seem to make more sense to me, since the test is presumably
there to check whether a relative URL can be constructed. This would
seemingly need the LEADING (not the TRAILING) part of "fullpath" to be
"baseurl". 

Also given the code in the "then" clause, which apparently (and
understandably) wants to strip the "baseurl" part out of "fullpath",
I'd expect the startswith method to be used in the if.

Finally, the entire reason I'm looking at this is that a local user
complained about the link individual lists on the mailing list
overview page being absolute URIs. Changing "endswith" to "startswith"
does the trick...

On the other hand, I'm not familiar with the mailman code, nor am I a
python programmer, so perhaps I'm missing something...?

TIA!,

  - Richard Geiger
    rmg@datadomain.com


From ricardo at rixhq.nu  Tue May 25 05:42:08 2004
From: ricardo at rixhq.nu (Ricardo)
Date: Tue May 25 05:42:19 2004
Subject: [Mailman-Developers] subzero?
Message-ID: <40B314F0.2000509@rixhq.nu>


I just got this on a new list I created...

"...mailing list has -1 request(s) waiting for your consideration at:"

That's kinda funny... now how am I supposed to approve -1 messages?

Ricardo.

From fil at rezo.net  Tue May 25 05:48:32 2004
From: fil at rezo.net (Fil)
Date: Tue May 25 05:47:30 2004
Subject: [Mailman-Developers] subzero?
In-Reply-To: <40B314F0.2000509@rixhq.nu>
References: <40B314F0.2000509@rixhq.nu>
Message-ID: <20040525094830.GH11987@rezo.net>

> "...mailing list has -1 request(s) waiting for your consideration at:"
> That's kinda funny... now how am I supposed to approve -1 messages?

Just refuse +1 message :)

I have the same bug. The -1 disappears once you go click on the "view the -1
messages" on the admin page.

-- Fil


From john.lange at bighostbox.com  Wed May 26 11:21:16 2004
From: john.lange at bighostbox.com (John Lange)
Date: Wed May 26 11:21:21 2004
Subject: [Mailman-Developers] Custom subject lines for subscribeack
Message-ID: <1085584876.24343.71.camel@ws101.darkcore.net>

Hello Developers.

I have a client that would like to customize the subject line of the
subscription acknowledgement message that mailman sends out when someone
successfully subscribes.

We have successfully customized the lists/<listname>/en/subscribeack.txt
message and it works great! However there does not appear to be any way
to change the subject line of that message.

I have searched the documentation, list archives, and finally the source
code. I could not find anything in the documentation or the archives but
the relevant lines of source code appear to be here:

Deliverer.py line 75

msg = Message.UserNotification(  
    self.GetMemberAdminEmail(name), self.GetRequestEmail(),
    _('Welcome to the "%(realname)s" mailing list%(digmode)s'),
    text, pluser)                                              

This appears to be a hard-coded subject line. :(

Would there be any work-around that wouldn't effect the subject line of
every list on the system?

Ultimately I believe there should be two new options added to the
General list information page right under "Send welcome message to newly
subscribed members?"

----

Subject line of Welcome message: Welcome to the "%(realname)s" mailing
list%(digmode)s

Body of Welcome message: <default body text>

----

Is there any chance this is something that might make it into Mailman
anytime soon?

Any suggestions, hints, rants etc. are welcome.

Thank you.

-- 
John Lange
BigHostBox.com
(204) 885 0872


From hopper at omnifarious.org  Thu May 27 12:14:25 2004
From: hopper at omnifarious.org (Eric M. Hopper)
Date: Thu May 27 12:14:13 2004
Subject: [Mailman-Developers] A Postfix patch
Message-ID: <1085674465.4159.91.camel@monster.omnifarious.org>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20040527/c825ab5e/attachment.bin
From hopper at omnifarious.org  Thu May 27 12:25:33 2004
From: hopper at omnifarious.org (Eric M. Hopper)
Date: Thu May 27 12:25:17 2004
Subject: [Mailman-Developers] Followup: A Postfix patch
Message-ID: <1085675133.4159.93.camel@monster.omnifarious.org>

The MIME policies on here are ridiculous.  I'm not going to jump through
50 hoops just to post a stupid small patch.  And I'm not going to stop
signing my email either.

*sigh*,
-- 
The best we can hope for concerning the people at large is that they
be properly armed.  -- Alexander Hamilton
-- Eric Hopper (hopper@omnifarious.org  http://www.omnifarious.org/~hopper) --
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/mailman-developers/attachments/20040527/766d7e9c/attachment.bin
From Matt_Domsch at dell.com  Fri May 28 14:47:43 2004
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Fri May 28 15:16:55 2004
Subject: [Mailman-Developers] 2.1.5: Incorrect -1 or 1 messages in moderator
	queue
Message-ID: <20040528184743.GA20151@lists.us.dell.com>

Submitted yesterday as Bug 961587.

Mailman 2.1.5, upgraded from 2.1.4.

Three different lists on the same server exhibit similar behaviour.

One list gets admin notices daily that there are -1 messages in the
moderator queue, when there are none displayed on the admindb page.

Two other list gets admin notices daily that there are 1 messages in
the moderator queue, when there are none displayed. For one list, I
have rmlist'd it and re-created it, to no avail.

Please advise.

Thanks,
Matt

-- 
Matt Domsch
Sr. Software Engineer, Lead Engineer
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

From tkikuchi at is.kochi-u.ac.jp  Fri May 28 17:24:14 2004
From: tkikuchi at is.kochi-u.ac.jp (Tokio Kikuchi)
Date: Fri May 28 17:24:30 2004
Subject: [Mailman-Developers] 2.1.5: Incorrect -1 or 1 messages in
	moderator queue
In-Reply-To: <20040528184743.GA20151@lists.us.dell.com>
References: <20040528184743.GA20151@lists.us.dell.com>
Message-ID: <40B7ADFE.5070200@is.kochi-u.ac.jp>



Matt Domsch wrote:

> Submitted yesterday as Bug 961587.
> 
> Mailman 2.1.5, upgraded from 2.1.4.
> 
> Three different lists on the same server exhibit similar behaviour.
> 
> One list gets admin notices daily that there are -1 messages in the
> moderator queue, when there are none displayed on the admindb page.

Try reload the admindb page. The notice of "-1 messages" stops for my
case.

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