From jon@csh.rit.edu Mon Jul 1 00:19:54 2002 From: jon@csh.rit.edu (Jon Parise) Date: Sun, 30 Jun 2002 19:19:54 -0400 Subject: [Mailman-Developers] messages/nl/LC_MESSAGES/mailman.mo Message-ID: <20020630231954.GE14266@csh.rit.edu> >From the latest CVS sources: install: nl/LC_MESSAGES/mailman.mo: No such file or directory *** Error code 71 It doesn't look like mailman.mo has been checked in for the Dutch translation. -- Jon Parise (jon@csh.rit.edu) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member From danny@terweij.nl Mon Jul 1 00:48:04 2002 From: danny@terweij.nl (Danny Terweij) Date: Mon, 1 Jul 2002 01:48:04 +0200 Subject: [Mailman-Developers] messages/nl/LC_MESSAGES/mailman.mo References: <20020630231954.GE14266@csh.rit.edu> Message-ID: <010201c22090$d6d5a3e0$1e00a8c0@onsnet.org> From: "Jon Parise" To: Sent: Monday, July 01, 2002 1:19 AM Subject: [Mailman-Developers] messages/nl/LC_MESSAGES/mailman.mo > >From the latest CVS sources: > > install: nl/LC_MESSAGES/mailman.mo: No such file or directory > *** Error code 71 > > It doesn't look like mailman.mo has been checked in for the Dutch > translation. Is correct, only th etemplates/nl/* are ready. I am working at the mailman.po file translation. Maybe Barry can copy the english mailman.mo to the nl directory ... The dutch mailman.po and mailman.mo is comming soon. Danny Terweij From barry@zope.com Mon Jul 1 14:32:16 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 1 Jul 2002 09:32:16 -0400 Subject: [Mailman-Developers] messages/nl/LC_MESSAGES/mailman.mo References: <20020630231954.GE14266@csh.rit.edu> <010201c22090$d6d5a3e0$1e00a8c0@onsnet.org> Message-ID: <15648.23008.432166.272757@anthem.wooz.org> >>>>> "DT" == Danny Terweij writes: DT> Maybe Barry can copy the english mailman.mo to the nl DT> directory ... Done. -Barry From noreply@sourceforge.net Mon Jul 1 19:03:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 01 Jul 2002 11:03:22 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-229568 ] Pipermail won't resolve author names of aol.com addresses Message-ID: Bugs item #229568, was opened at 2001-01-20 22:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=229568&group_id=103 Category: Pipermail Group: None Status: Open Resolution: Works For Me Priority: 5 Submitted By: Aharon Varady (aharon) Assigned to: Nobody/Anonymous (nobody) Summary: Pipermail won't resolve author names of aol.com addresses Initial Comment: Pipermail does not resolve the "author" of emails sent from aol.com. Instead, Pipermail gives the email address of the listserve. For example: "John" is resolved by pipermail as: listname@foo.com and not as John. This bug only occurs for users of aol.com addresses. ---------------------------------------------------------------------- Comment By: Terri Oda (spot) Date: 2002-07-01 14:03 Message: Logged In: YES user_id=110886 The problem is that it defaults to using the reply-to address if it's set, and this isn't what we want when the reply-to is always being set by the list. Take a careful look at the rest of your archives and you'll probably note that *everyone's* email address is showing up as listname@foo.com. It's a nice anti-spam feature, perhaps, but probably not what you want. Here's a quick fix for pipermail.py: 180c180 < if e is not None: --- > if e is not None and self.email is None: This just changes it so that it defaults to the From: address (when it's set) rather than the Reply-to address. If there's some particular reason to take the Reply-To over the From, I can make something which actually checks to see if the reply-to is being set by the list, but this should solve your problem for the moment. Terri ---------------------------------------------------------------------- Comment By: Ava Jarvis (katanalynx) Date: 2002-06-10 22:14 Message: Logged In: YES user_id=561110 This bug -- for version 2.0.11 at least -- seems to occur when 'from' only contains the email address. There's some code in pipermail.py (version 2.0.11), line 177: # Figure out the e-mail address and poster's name self.author, self.email = message.getaddr('From') e = message.getheader('Reply-To') if e is not None: self.email = e self.email = strip_separators(self.email) self.author = strip_separators(self.author) if self.author == "": self.author = self.email If reply-to is set, then it is always taken as the author's email address. However, some lists set the reply-to field to be, for instance, the list address.... and you can guess what happens next when there is no name comment/author. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-06 12:09 Message: Logged In: NO This comment doesn't directly address the case you report, but it might be related so I thought it worthwhile to submit. I see you are using MM2.0.9. I saw a similar problem with MM2.1b1, which was fixed in MM2.1b2. The problem then was that an address with a name "comment" would be displayed in the archive as the list name, whereas an address with a name comment would be displayed (properly) with the name. Example: "John Doe" jdoe@whereever.com displayed as "John Doe" whereas jdoe@whereever.com displayed as the list name. In your comment, you use an example with a name comment of "John", but in the example you provided there is no name comment field, so perhaps my statements here do apply. ---------------------------------------------------------------------- Comment By: Aharon Varady (aharon) Date: 2002-06-05 21:37 Message: Logged In: YES user_id=139355 Well, this remains (and has always been) a problem for my lists. I have never had a user posting with an aol.com address that this hasn't been the case with. Currently my solution is to replace the wrong address shown (philly_ambient@phobos.serve.com) with a generic or balnk mark. Here is the html source of a typical email from our pipermail archive, and below it the source email with headers. ------------------------------------------------------------- [Philly_ambient] tool!

    [Philly_ambient] tool!

    Posted by . . . .. . . . on Mon Jun 3 23:17:02 2002 

    hey all
a friend can get me some free tickets to see TOOL on monday
august 12 at 
sovereign bank arena in trenton. i know mondays suck, but oh
well. is anyone 
here into going?  if so, contact me privately.  i know it's
not ambient, but 
neither is some of what we discuss here :)
let me know asap, please

gina

  • Previous message: [Philly_ambient] Noise Deafinitions and playlist
  • Next message: [Philly_ambient] Do you hear what I hear? (re: noise deaf)
  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
    • --------------------------------------------------------------------- Here is the original email with headers: --------------------------------------------------------------- >From - Tue Jun 04 01:16:56 2002 X-UIDL: m;n!!9'f!!a2E"!3;D"! X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: aharon@phobos.serve.com Received: from phobos.serve.com (localhost.localdomain [127.0.0.1]) by phobos.serve.com (Postfix) with ESMTP id 6BC4D52D2B; Mon, 3 Jun 2002 23:17:06 -0400 (EDT) Delivered-To: philly_ambient@phobos.serve.com Received: from imo-r06.mx.aol.com (imo-r06.mx.aol.com [152.163.225.102]) by phobos.serve.com (Postfix) with ESMTP id 6F82F52D1D for ; Mon, 3 Jun 2002 23:16:46 -0400 (EDT) Received: from Mistsojorn@aol.com by imo-r06.mx.aol.com (mail_out_v32.5.) id p.d4.184e63f9 (17378) for ; Mon, 3 Jun 2002 23:14:35 -0400 (EDT) From: Mistsojorn@aol.com Message-ID: To: philly_ambient@phobos.serve.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 4.0 for Mac - Post-GM sub 66 Subject: [Philly_ambient] tool! Sender: philly_ambient-admin@phobos.serve.com Errors-To: philly_ambient-admin@phobos.serve.com X-BeenThere: philly_ambient@phobos.serve.com X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: philly_ambient@phobos.serve.com List-Help: List-Post: List-Subscribe: , List-Id: a discussion list relevant to Philadelphia Ambient and Experimental Psychedelic Music Enthusiasts List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 3 Jun 2002 23:14:35 EDT Date: Mon, 3 Jun 2002 23:14:35 EDT X-UIDL: m;n!!9'f!!a2E"!3;D"! hey all a friend can get me some free tickets to see TOOL on monday august 12 at sovereign bank arena in trenton. i know mondays suck, but oh well. is anyone here into going? if so, contact me privately. i know it's not ambient, but neither is some of what we discuss here :) let me know asap, please gina _______________________________________________ Philly_ambient mailing list Philly_ambient@phobos.serve.com Subscribe, Unsubscribe, Edit Options at: http://phobos.serve.com/mailman/listinfo/philly_ambient a PAC(MaN) List http://simpletone.com -------------------------------------------------------------------- I don't know why pipermail would treat my aol subscribers different either. But it is. Aharon ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-04-28 21:11 Message: Logged In: YES user_id=12800 Bizarre. I've never seen this, and I can't see any reason why Pipermail would treat aol.com addresses any different. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=229568&group_id=103 From alan@rdrop.com Tue Jul 2 06:33:04 2002 From: alan@rdrop.com (Alan Batie) Date: Mon, 1 Jul 2002 22:33:04 -0700 Subject: [Mailman-Developers] A quick pointer Message-ID: <20020701223304.B20862@agora.rdrop.com> I'll confess I've never hacked python, but it looks pretty straightforward and I'm really tired of going in and weeding out the spam from my several lists every few days. The FAQ for tossing everything is tempting, but I'd like to fix it right and add a setting that says "Discard every post not from a subscriber". I was hoping I could get three quick pointers here so I don't have to wade through the whole thing: 1. Where do the settings listed on the web page get set? 2. Where do they get processed when you submit the form? (I'm assuming looking at this will also tell me how to query the setting later) 3. Where does the decision of what to do with a message not from a subscriber happen? I can probably find this searching through the code, but I thought posting here would a) let people know someone was attempting this, b) tell me if someone else is already doing it and c) maybe someone would let me know if there are any "surprises" lurking... Thanks... -- Alan Batie ______ www.rdrop.com/users/alan Me alan@batie.org \ / www.qrd.org The Triangle PGPFP DE 3C 29 17 C0 49 7A \ / www.pgpi.com The Weird Numbers 27 40 A5 3C 37 4A DA 52 B9 \/ razor.sourceforge.net NO SPAM! A free society is a place where it's safe to be unpopular. -Adlai Stevenson, statesman (1900-1965) From fil@rezo.net Tue Jul 2 16:54:46 2002 From: fil@rezo.net (Fil) Date: Tue, 2 Jul 2002 17:54:46 +0200 Subject: [Mailman-Developers] quite a few problems with current cvs Message-ID: <20020702155446.GA1971@rezo.net> Dear Mailman-dev, since I last upgraded I can't make mailman work as it used to! 1) Most importantly and urgently, the confirmation emails do not trigger subscriptions any more : the user receives her "You are subscribed" email, but she does not appear in the subscribers' roster, and her cookie is still there in data/pending.pck 2) A secondary issue is that the iso-something subject lines are totally broken ; I think this is related to the impossibility of installing email-2.0.4 on a python 2.1 box (the _compat22.py file fails and exit) but I'm not sure. What can I do to help track it down/ repair my system? -- Fil From barry@zope.com Tue Jul 2 17:04:15 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 2 Jul 2002 12:04:15 -0400 Subject: [Mailman-Developers] quite a few problems with current cvs References: <20020702155446.GA1971@rezo.net> Message-ID: <15649.52991.905916.345049@anthem.wooz.org> >>>>> "F" == Fil writes: F> 1) Most importantly and urgently, the confirmation emails do F> not trigger F> subscriptions any more : the user receives her "You are F> subscribed" email, but she does not appear in the subscribers' F> roster, and her cookie is still there in data/pending.pck I'll look into this one. F> 2) A secondary issue is that the iso-something subject lines F> are totally F> broken ; I think this is related to the impossibility of F> installing email-2.0.4 on a python 2.1 box (the _compat22.py F> file fails and exit) but I'm not sure. Wasn't there a report about problems with _compat.py on a Python 2.1 beta? Be sure you're running Python 2.1.3. There is going to be a new email package shortly, but first I'm trying to finish up MM2.0.12. -Barry From fil@rezo.net Tue Jul 2 17:16:38 2002 From: fil@rezo.net (Fil) Date: Tue, 2 Jul 2002 18:16:38 +0200 Subject: [Mailman-Developers] quite a few problems with current cvs In-Reply-To: <15649.52991.905916.345049@anthem.wooz.org> References: <20020702155446.GA1971@rezo.net> <15649.52991.905916.345049@anthem.wooz.org> Message-ID: <20020702161638.GB3827@rezo.net> @ Barry A. Warsaw : > Wasn't there a report about problems with _compat.py on a Python 2.1 > beta? Be sure you're running Python 2.1.3. I've upgraded python, to no avail: miel:~/mailman/mailman/misc/email-2.0.4# python -V Python 2.1.3 miel:~/mailman/mailman/misc/email-2.0.4# python setup.py install [snip] skipping byte-compilation of /usr/lib/python2.1/site-packages/email/_compat21.py to _compat21.pyc byte-compiling /usr/lib/python2.1/site-packages/email/_compat22.py to _compat22.pyc File "/usr/lib/python2.1/site-packages/email/_compat22.py", line 21 yield self ^ SyntaxError: invalid syntax -- Fil From barry@zope.com Tue Jul 2 17:25:27 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 2 Jul 2002 12:25:27 -0400 Subject: [Mailman-Developers] quite a few problems with current cvs References: <20020702155446.GA1971@rezo.net> <15649.52991.905916.345049@anthem.wooz.org> <20020702161638.GB3827@rezo.net> Message-ID: <15649.54263.722207.93009@anthem.wooz.org> ---------------------- multipart/mixed attachment Try this setup.py file, which is part email 2.0.5 -Barry ---------------------- multipart/mixed attachment #! /usr/bin/env python # # Copyright (C) 2001,2002 Python Software Foundation # Standard distutils setup.py install script for the `mimelib' library, a next # generation MIME library for Python. To install into your existing Python # distribution, run the following at the command line: # # % python setup.py install import sys from os.path import basename from distutils.core import setup from distutils.command.install_lib import install_lib class EmailInstall(install_lib): def byte_compile(self, files): # For Python 2.1.x do not byte compile the _compat22.py file since # that will most definitely fail. Any newer Python can compile # everything. major, minor = sys.version_info[0:2] if major == 2 and minor == 1: files = [f for f in files if basename(f) <> '_compat22.py'] return install_lib.byte_compile(self, files) setup(name='email', version='2.0.5', description='Next generation MIME library', author='Barry Warsaw', author_email='barry@zope.com', url='http://sf.net/projects/mimelib', packages=['email'], # Because we need to selectively byte-compile cmdclass={'install_lib': EmailInstall}, ) ---------------------- multipart/mixed attachment-- From fil@rezo.net Tue Jul 2 17:28:36 2002 From: fil@rezo.net (Fil) Date: Tue, 2 Jul 2002 18:28:36 +0200 Subject: [Mailman-Developers] quite a few problems with current cvs In-Reply-To: <15649.54263.722207.93009@anthem.wooz.org> References: <20020702155446.GA1971@rezo.net> <15649.52991.905916.345049@anthem.wooz.org> <20020702161638.GB3827@rezo.net> <15649.54263.722207.93009@anthem.wooz.org> Message-ID: <20020702162836.GB8751@rezo.net> > Try this setup.py file, which is part email 2.0.5 > -Barry It rocks! -- Fil From fil@rezo.net Tue Jul 2 17:31:40 2002 From: fil@rezo.net (Fil) Date: Tue, 2 Jul 2002 18:31:40 +0200 Subject: [Mailman-Developers] quite a few problems with current cvs In-Reply-To: <20020702162836.GB8751@rezo.net> References: <20020702155446.GA1971@rezo.net> <15649.52991.905916.345049@anthem.wooz.org> <20020702161638.GB3827@rezo.net> <15649.54263.722207.93009@anthem.wooz.org> <20020702162836.GB8751@rezo.net> Message-ID: <20020702163140.GE8751@rezo.net> > > Try this setup.py file, which is part email 2.0.5 > > -Barry > > It rocks! I meant "The setup.py rocks!", because it doesn't help mailman deal with the iso-xxx subject lines. Here's what I get: Subject: [Test] =?iso-8859-1?Q?accentu=E9es_=E8_=E0_=F4?= -- Fil From barry@zope.com Tue Jul 2 18:07:43 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 2 Jul 2002 13:07:43 -0400 Subject: [Mailman-Developers] quite a few problems with current cvs References: <20020702155446.GA1971@rezo.net> <15649.52991.905916.345049@anthem.wooz.org> <20020702161638.GB3827@rezo.net> <15649.54263.722207.93009@anthem.wooz.org> <20020702162836.GB8751@rezo.net> <20020702163140.GE8751@rezo.net> Message-ID: <15649.56799.12552.273761@anthem.wooz.org> >>>>> "F" == Fil writes: >> Try this setup.py file, which is part email 2.0.5 -Barry >> It rocks! F> I meant "The setup.py rocks!", because it doesn't help mailman F> deal with the iso-xxx subject lines. Here's what I get: F> Subject: [Test] =?iso-8859-1?Q?accentu=E9es_=E8_=E0_=F4?= Glad the setup.py works. Now by "doesn't help mailman deal with the iso-xxx buject lines", what exactly does that mean? Is that a problem in the archives? In digests? Some place else? -Barry From csm@moongroup.com Tue Jul 2 19:43:16 2002 From: csm@moongroup.com (Chuck Mead) Date: Tue, 02 Jul 2002 14:43:16 -0400 Subject: [Mailman-Developers] drop mail from posters who are not subscribed! Message-ID: <3D21F444.1070200@moongroup.com> Does anybody have a patch making it possible to simply drop mail sent from posters who are not subscribed? I run a pile of lists (none of them accept mail from people who are not subscribed) and I get quite tired of having to manually deal with spam posts from people who are not subscribed to the lists. Any ideas? -- csm "Look, I want to make Microsoft's life miserable; so I'll tell you what, I'll pay you $10 million a year to torture Microsoft." --Steve Ballmer From noreply@sourceforge.net Tue Jul 2 21:00:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jul 2002 13:00:58 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-229568 ] Pipermail won't resolve author names of aol.com addresses Message-ID: Bugs item #229568, was opened at 2001-01-20 22:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=229568&group_id=103 Category: Pipermail Group: None Status: Open Resolution: Works For Me Priority: 5 Submitted By: Aharon Varady (aharon) Assigned to: Nobody/Anonymous (nobody) Summary: Pipermail won't resolve author names of aol.com addresses Initial Comment: Pipermail does not resolve the "author" of emails sent from aol.com. Instead, Pipermail gives the email address of the listserve. For example: "John" is resolved by pipermail as: listname@foo.com and not as John. This bug only occurs for users of aol.com addresses. ---------------------------------------------------------------------- Comment By: Terri Oda (spot) Date: 2002-07-02 16:00 Message: Logged In: YES user_id=110886 Whoops. Diffed the wrong thing. That's what happens when I try to patch code but haven't slept in a few days. This actually works better: 180c180 < if e is not None: --- > if e is not None and self.email == "": ---------------------------------------------------------------------- Comment By: Terri Oda (spot) Date: 2002-07-01 14:03 Message: Logged In: YES user_id=110886 The problem is that it defaults to using the reply-to address if it's set, and this isn't what we want when the reply-to is always being set by the list. Take a careful look at the rest of your archives and you'll probably note that *everyone's* email address is showing up as listname@foo.com. It's a nice anti-spam feature, perhaps, but probably not what you want. Here's a quick fix for pipermail.py: 180c180 < if e is not None: --- > if e is not None and self.email is None: This just changes it so that it defaults to the From: address (when it's set) rather than the Reply-to address. If there's some particular reason to take the Reply-To over the From, I can make something which actually checks to see if the reply-to is being set by the list, but this should solve your problem for the moment. Terri ---------------------------------------------------------------------- Comment By: Ava Jarvis (katanalynx) Date: 2002-06-10 22:14 Message: Logged In: YES user_id=561110 This bug -- for version 2.0.11 at least -- seems to occur when 'from' only contains the email address. There's some code in pipermail.py (version 2.0.11), line 177: # Figure out the e-mail address and poster's name self.author, self.email = message.getaddr('From') e = message.getheader('Reply-To') if e is not None: self.email = e self.email = strip_separators(self.email) self.author = strip_separators(self.author) if self.author == "": self.author = self.email If reply-to is set, then it is always taken as the author's email address. However, some lists set the reply-to field to be, for instance, the list address.... and you can guess what happens next when there is no name comment/author. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-06-06 12:09 Message: Logged In: NO This comment doesn't directly address the case you report, but it might be related so I thought it worthwhile to submit. I see you are using MM2.0.9. I saw a similar problem with MM2.1b1, which was fixed in MM2.1b2. The problem then was that an address with a name "comment" would be displayed in the archive as the list name, whereas an address with a name comment would be displayed (properly) with the name. Example: "John Doe" jdoe@whereever.com displayed as "John Doe" whereas jdoe@whereever.com displayed as the list name. In your comment, you use an example with a name comment of "John", but in the example you provided there is no name comment field, so perhaps my statements here do apply. ---------------------------------------------------------------------- Comment By: Aharon Varady (aharon) Date: 2002-06-05 21:37 Message: Logged In: YES user_id=139355 Well, this remains (and has always been) a problem for my lists. I have never had a user posting with an aol.com address that this hasn't been the case with. Currently my solution is to replace the wrong address shown (philly_ambient@phobos.serve.com) with a generic or balnk mark. Here is the html source of a typical email from our pipermail archive, and below it the source email with headers. ------------------------------------------------------------- [Philly_ambient] tool!

      [Philly_ambient] tool!

      Posted by . . . .. . . . on Mon Jun 3 23:17:02 2002 

      hey all
a friend can get me some free tickets to see TOOL on monday
august 12 at 
sovereign bank arena in trenton. i know mondays suck, but oh
well. is anyone 
here into going?  if so, contact me privately.  i know it's
not ambient, but 
neither is some of what we discuss here :)
let me know asap, please

gina

    • Previous message: [Philly_ambient] Noise Deafinitions and playlist
    • Next message: [Philly_ambient] Do you hear what I hear? (re: noise deaf)
    • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
      • --------------------------------------------------------------------- Here is the original email with headers: --------------------------------------------------------------- >From - Tue Jun 04 01:16:56 2002 X-UIDL: m;n!!9'f!!a2E"!3;D"! X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: aharon@phobos.serve.com Received: from phobos.serve.com (localhost.localdomain [127.0.0.1]) by phobos.serve.com (Postfix) with ESMTP id 6BC4D52D2B; Mon, 3 Jun 2002 23:17:06 -0400 (EDT) Delivered-To: philly_ambient@phobos.serve.com Received: from imo-r06.mx.aol.com (imo-r06.mx.aol.com [152.163.225.102]) by phobos.serve.com (Postfix) with ESMTP id 6F82F52D1D for ; Mon, 3 Jun 2002 23:16:46 -0400 (EDT) Received: from Mistsojorn@aol.com by imo-r06.mx.aol.com (mail_out_v32.5.) id p.d4.184e63f9 (17378) for ; Mon, 3 Jun 2002 23:14:35 -0400 (EDT) From: Mistsojorn@aol.com Message-ID: To: philly_ambient@phobos.serve.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 4.0 for Mac - Post-GM sub 66 Subject: [Philly_ambient] tool! Sender: philly_ambient-admin@phobos.serve.com Errors-To: philly_ambient-admin@phobos.serve.com X-BeenThere: philly_ambient@phobos.serve.com X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: philly_ambient@phobos.serve.com List-Help: List-Post: List-Subscribe: , List-Id: a discussion list relevant to Philadelphia Ambient and Experimental Psychedelic Music Enthusiasts List-Unsubscribe: , List-Archive: X-Original-Date: Mon, 3 Jun 2002 23:14:35 EDT Date: Mon, 3 Jun 2002 23:14:35 EDT X-UIDL: m;n!!9'f!!a2E"!3;D"! hey all a friend can get me some free tickets to see TOOL on monday august 12 at sovereign bank arena in trenton. i know mondays suck, but oh well. is anyone here into going? if so, contact me privately. i know it's not ambient, but neither is some of what we discuss here :) let me know asap, please gina _______________________________________________ Philly_ambient mailing list Philly_ambient@phobos.serve.com Subscribe, Unsubscribe, Edit Options at: http://phobos.serve.com/mailman/listinfo/philly_ambient a PAC(MaN) List http://simpletone.com -------------------------------------------------------------------- I don't know why pipermail would treat my aol subscribers different either. But it is. Aharon ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-04-28 21:11 Message: Logged In: YES user_id=12800 Bizarre. I've never seen this, and I can't see any reason why Pipermail would treat aol.com addresses any different. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=229568&group_id=103 From fil@rezo.net Tue Jul 2 21:33:26 2002 From: fil@rezo.net (Fil) Date: Tue, 2 Jul 2002 22:33:26 +0200 Subject: [Mailman-Developers] quite a few problems with current cvs In-Reply-To: <15649.56799.12552.273761@anthem.wooz.org> References: <20020702155446.GA1971@rezo.net> <15649.52991.905916.345049@anthem.wooz.org> <20020702161638.GB3827@rezo.net> <15649.54263.722207.93009@anthem.wooz.org> <20020702162836.GB8751@rezo.net> <20020702163140.GE8751@rezo.net> <15649.56799.12552.273761@anthem.wooz.org> Message-ID: <20020702203326.GA24512@rezo.net> @ Barry A. Warsaw : > F> Subject: [Test] =?iso-8859-1?Q?accentu=E9es_=E8_=E0_=F4?= > > Glad the setup.py works. > > Now by "doesn't help mailman deal with the iso-xxx buject lines", what > exactly does that mean? Is that a problem in the archives? In > digests? Some place else? The emails received have this subject line, shown as above. They are not interpreted by 'mutt', nor by a webmail I use (squirrelmail), nor by Eudora, nor by mhonarc (see e.g. http://listes.rezo.net/archives/spip/2002-07/msg00039.html ). So I guess it's not coming from mutt or the other MUAs being suddenly broken, but rather them being badly formed somewhere in Mailman. -- Fil From fil@rezo.net Tue Jul 2 22:17:34 2002 From: fil@rezo.net (Fil) Date: Tue, 2 Jul 2002 23:17:34 +0200 Subject: [Mailman-Developers] quite a few problems with current cvs In-Reply-To: <20020702203326.GA24512@rezo.net> References: <20020702155446.GA1971@rezo.net> <15649.52991.905916.345049@anthem.wooz.org> <20020702161638.GB3827@rezo.net> <15649.54263.722207.93009@anthem.wooz.org> <20020702162836.GB8751@rezo.net> <20020702163140.GE8751@rezo.net> <15649.56799.12552.273761@anthem.wooz.org> <20020702203326.GA24512@rezo.net> Message-ID: <20020702211734.GA28647@rezo.net> > The emails received have this subject line, shown as above. If some wizards want to see it better, they can download a test message I sent to myself through Mailman and directly. Originals are at http://rezo.net/~fil/mailman/accents.gz ; the mailbox file itself contains: >>>>>>>>>>> Subject: test =?iso-8859-1?Q?caract=E8res_accentu?= =?iso-8859-1?B?6XMg4Onu9A==?= (nice encoding, shows good in all MUAs) >>>>>>>>>>> Subject: =?iso-8859-1?q?=5BTest=5D_?= =?iso-8859-1?q?test_=3D=3Fiso-8859-1=3FQ=3Fcaract=3DE8res=5Faccentu=3F=3D?= =?iso-8859-1?q?=0D=0A=09=3D=3Fiso-8859-1=3FB=3F6XMg4Onu9A=3D=3D=3F=3D?= (double encoding, shows bad in all MUAs) >>>>>>>>>>> The mail server and my own email are the same machine, so no interference existed. -- Fil From noreply@sourceforge.net Wed Jul 3 05:02:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 02 Jul 2002 21:02:28 -0700 Subject: [Mailman-Developers] [ mailman-Patches-534577 ] Add SpamAssassin filter to mail pipeline Message-ID: Patches item #534577, was opened at 2002-03-25 16:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=534577&group_id=103 Category: list administration Group: Mailman 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: Add SpamAssassin filter to mail pipeline Initial Comment: This filter adds support for discarding or holding spam sent to the mailing list. It contacts a spamd daemon (from SpamAssassin -- http://spamassassin.taint.org) to score the message. If the score is above a certain threshold (default 10), the message is discarded and an entry is written to the vette log. If the score is above another lower threshold (default 5), the message is held for moderation. The SpamAssassin.py file should be installed in Mailman/Handlers/. The LIST_PIPELINE variable in Mailman/Handlers/HandlerAPI.py should be modified to include a 'SpamAssassin' item (I put it just after the existing 'SpamDetect' item). To change the defaults, the following can be added to the mm_cfg.py file: SPAMASSASSIN_HOST = 'host:port' # how to contact SA SPAMASSASSIN_DISCARD_SCORE = 10 SPAMASSASSIN_HOLD_SCORE = 5 If you don't want to discard messages, then DISCARD_SCORE can be set to something very high (1000 should do it). It looks the MM2.1 filter APIs have changed a bit, so this filter will need some modifications to work with that version. When I get round to upgrading, I might look into updating it. ---------------------------------------------------------------------- >Comment By: James Henstridge (jhenstridge) Date: 2002-07-03 12:02 Message: Logged In: YES user_id=146903 Yet another version. There were some bugs in handling of certain error conditions when talking to spamd. These would result in exceptions and the messages staying in the delivery queue :( With the new version, the message will be passed through unchecked under these conditions, and a message will be added to the error log. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2002-06-13 05:48 Message: Logged In: YES user_id=81797 FYI: I've been running the 2002-05-14 version of this patch with spamassassin 2.20 for the last day on our main mailman box and it seems to be working great. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-05-14 14:04 Message: Logged In: YES user_id=146903 This version is essentially the same as the previous version, but adds compatibility with python > 1.5.2, which doesn't like you passing two arguments to socket.connect(). ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-04-27 14:17 Message: Logged In: YES user_id=146903 Just attached my updated version of the patch. This version requires SpamAssassin 2.20 (for the extra commands that the spamd daemon understands). It now displays a list of which rules were triggered for held messages, and can give messages from list members a bonus (defaults to 2), so that they are less likely to get held as spam. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-03-26 09:21 Message: Logged In: YES user_id=146903 There is a fairly easy optimisation for this filter that I missed when writing it. It calls str() on the message object twice. It would be quicker to call str() on the message once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=534577&group_id=103 From barry@zope.com Wed Jul 3 05:56:24 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 3 Jul 2002 00:56:24 -0400 Subject: [Mailman-Developers] quite a few problems with current cvs References: <20020702155446.GA1971@rezo.net> Message-ID: <15650.33784.871959.802697@anthem.wooz.org> >>>>> "F" == Fil writes: F> 1) Most importantly and urgently, the confirmation emails do F> not trigger subscriptions any more : the user receives her "You are F> subscribed" email, but she does not appear in the subscribers' F> roster, and her cookie is still there in data/pending.pck FWIW, I can't confirm this with current cvs. Email subscriptions, confirmations, unsubs, confirmations, all seem to work just fine. -Barry From barry@zope.com Wed Jul 3 06:43:20 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 3 Jul 2002 01:43:20 -0400 Subject: [Mailman-Developers] quite a few problems with current cvs References: <20020702155446.GA1971@rezo.net> <15649.52991.905916.345049@anthem.wooz.org> <20020702161638.GB3827@rezo.net> <15649.54263.722207.93009@anthem.wooz.org> <20020702162836.GB8751@rezo.net> <20020702163140.GE8751@rezo.net> <15649.56799.12552.273761@anthem.wooz.org> <20020702203326.GA24512@rezo.net> Message-ID: <15650.36600.565124.969268@anthem.wooz.org> >>>>> "F" == Fil writes: > Subject: [Test] =?iso-8859-1?Q?accentu=E9es_=E8_=E0_=F4?= F> The emails received have this subject line, shown as F> above. They are not interpreted by 'mutt', nor by a webmail I F> use (squirrelmail), nor by Eudora, nor by mhonarc (see e.g. F> http://listes.rezo.net/archives/spip/2002-07/msg00039.html ). F> So I guess it's not coming from mutt or the other MUAs being F> suddenly broken, but rather them being badly formed somewhere F> in Mailman. I wouldn't count on it. I believe the header is conformant to RFC 2047: Ordinary ASCII text and 'encoded-word's may appear together in the same header field. However, an 'encoded-word' that appears in a header field defined as '*text' MUST be separated from any adjacent 'encoded-word' or 'text' by 'linear-white-space'. and indeed this header displays just fine in VM/XEmacs. | | Subject: test =?iso-8859-1?Q?caract=E8res_accentu?= | =?iso-8859-1?B?6XMg4Onu9A==?= | (nice encoding, shows good in all MUAs) Yup, in mine too. | Subject: =?iso-8859-1?q?=5BTest=5D_?= | =?iso-8859-1?q?test_=3D=3Fiso-8859-1=3FQ=3Fcaract=3DE8res=5Faccentu=3F=3D?= | =?iso-8859-1?q?=0D=0A=09=3D=3Fiso-8859-1=3FB=3F6XMg4Onu9A=3D=3D=3F=3D?= F> The mail server and my own email are the same machine, so no F> interference existed. Hmm. Can you send me the original test message? I'd like to know who in email or Mailman is doing the touble encoding. But isn't this seems like a different problem than the one you described earlier? In the first case, the mixing of ascii and encoded-words should be legal. In the second, you're getting encoded-words double encoded, which is clearly wrong, but I don't know where that's coming from. -Barry From fil@rezo.net Wed Jul 3 10:16:14 2002 From: fil@rezo.net (Fil) Date: Wed, 3 Jul 2002 11:16:14 +0200 Subject: [Mailman-Developers] quite a few problems with current cvs In-Reply-To: <15650.33784.871959.802697@anthem.wooz.org> References: <20020702155446.GA1971@rezo.net> <15650.33784.871959.802697@anthem.wooz.org> Message-ID: <20020703091614.GA9709@rezo.net> @ Barry A. Warsaw : > F> 1) Most importantly and urgently, the confirmation emails do > F> not trigger subscriptions any more : the user receives her "You are > F> subscribed" email, but she does not appear in the subscribers' > F> roster, and her cookie is still there in data/pending.pck > > FWIW, I can't confirm this with current cvs. Email subscriptions, > confirmations, unsubs, confirmations, all seem to work just fine. Strangely, the web confirmation works perfectly, only the email confirmations fail. The email confirmation apparently works (the user receives all the correct emails) but the cookie stays in the pending.pck and the user is not subscribed... I've changed my verify.txt to send everybody to the web confirmation interface, but still, I'm wondering what can be the difference: a lock condition maybe? I've checked permissions, they're all apparently OK... -- Fil From alan@batie.org Wed Jul 3 10:22:25 2002 From: alan@batie.org (Alan Batie) Date: Wed, 3 Jul 2002 02:22:25 -0700 Subject: [Mailman-Developers] Discard patch Message-ID: <20020703022225.A65576@agora.rdrop.com> ---------------------- multipart/mixed attachment I still think that a language that applies semantics to indentation is silly (though I can remember wishing for it a few times when I was learning programming ;-) ), but at least you guys have written good readable code, even for a non-python guy. Here's the patches to add "discard_nonmember_postings" as an option; it only has effect if member_posting_only is also set and the datafile version is revved to 22 to add it in automatically. I was trying to fix the fact that member_posting_only doesn't properly default, but it seems to be in RadioButtonArray and I can't find that anywhere, either in mailman or in python. Maybe it's cuz it's after 2am. Oh well. While I was looking at that, I saw a comment that said something like "i'd rather have Logout have a blank line in front of it instead of being a big font", so I fixed that too --- kindof a hack, but one I find works well all over the place. That's the second patch, FWIW... -- Alan Batie ______ www.rdrop.com/users/alan Me alan@batie.org \ / www.qrd.org The Triangle PGPFP DE 3C 29 17 C0 49 7A \ / www.pgpi.com The Weird Numbers 27 40 A5 3C 37 4A DA 52 B9 \/ razor.sourceforge.net NO SPAM! A free society is a place where it's safe to be unpopular. -Adlai Stevenson, statesman (1900-1965) ---------------------- multipart/mixed attachment *** Handlers/Hold.py.org Wed Jul 3 01:14:43 2002 --- Handlers/Hold.py Wed Jul 3 01:15:16 2002 *************** *** 149,155 **** not Utils.FindMatchingAddresses(sender, posters): # the sender is neither a member of the list, nor in the list of # explicitly approved posters ! hold_for_approval(mlist, msg, msgdata, NonMemberPost) # no return elif mlist.posters: posters = Utils.List2Dict(map(string.lower, mlist.posters)) --- 149,159 ---- not Utils.FindMatchingAddresses(sender, posters): # the sender is neither a member of the list, nor in the list of # explicitly approved posters ! if mlist.discard_nonmember_postings: ! # if discarding, just signal all done ! raise NonMemberPost ! else: ! hold_for_approval(mlist, msg, msgdata, NonMemberPost) # no return elif mlist.posters: posters = Utils.List2Dict(map(string.lower, mlist.posters)) *** Defaults.py.in.org Wed Jul 3 01:19:57 2002 --- Defaults.py.in Wed Jul 3 01:19:59 2002 *************** *** 342,348 **** DEFAULT_OBSCURE_ADDRESSES = 1 # Make it 1 when it works. ! DEFAULT_MEMBER_POSTING_ONLY = 0 --- 342,351 ---- DEFAULT_OBSCURE_ADDRESSES = 1 # Make it 1 when it works. ! DEFAULT_MEMBER_POSTING_ONLY = 1 ! ! # Discard mail from non-members --- it's all spam anyway ! DEFAULT_DISCARD_NONMEMBER_POSTINGS = 0 *** MailList.py.org Tue Jul 2 22:36:41 2002 --- MailList.py Wed Jul 3 01:13:57 2002 *************** *** 323,328 **** --- 323,329 ---- self.private_roster = mm_cfg.DEFAULT_PRIVATE_ROSTER self.obscure_addresses = mm_cfg.DEFAULT_OBSCURE_ADDRESSES self.member_posting_only = mm_cfg.DEFAULT_MEMBER_POSTING_ONLY + self.discard_nonmember_postings = mm_cfg.DEFAULT_DISCARD_NONMEMBER_POSTINGS self.host_name = mm_cfg.DEFAULT_HOST_NAME self.admin_member_chunksize = mm_cfg.DEFAULT_ADMIN_MEMBER_CHUNKSIZE self.administrivia = mm_cfg.DEFAULT_ADMINISTRIVIA *************** *** 660,665 **** --- 661,674 ---- " If you want list members to be able to" " post, plus a handful of other posters, see the posters " " setting below"), + + ('discard_nonmember_postings', mm_cfg.Radio, ('No', 'Yes'), 0, + 'Discard postings from non-members?' + ' (discard_nonmember_postings)', + + "Use this option if you want to automatically discard postings" + " from non-members --- it's usually just spam. Otherwise, it" + " is held and you have to deal with it."), ('posters', mm_cfg.EmailList, (5, WIDTH), 1, 'Addresses of members accepted for posting to this' *** Version.py.org Wed Jul 3 01:13:06 2002 --- Version.py Wed Jul 3 01:13:57 2002 *************** *** 36,42 **** (REL_LEVEL << 4) | (REL_SERIAL << 0)) # config.db schema version number ! DATA_FILE_VERSION = 21 # qfile/*.db schema version number QFILE_SCHEMA_VERSION = 2 --- 36,42 ---- (REL_LEVEL << 4) | (REL_SERIAL << 0)) # config.db schema version number ! DATA_FILE_VERSION = 22 # qfile/*.db schema version number QFILE_SCHEMA_VERSION = 2 *** versions.py.org Wed Jul 3 01:13:17 2002 --- versions.py Wed Jul 3 01:13:57 2002 *************** *** 189,194 **** --- 189,195 ---- add_only_if_missing('postings_responses', {}, l) add_only_if_missing('admin_responses', {}, l) add_only_if_missing('reply_goes_to_list', '', l) + add_only_if_missing('discard_nonmember_postings', 0, l) ---------------------- multipart/mixed attachment *** admin.py.org Wed Jul 3 01:35:10 2002 --- admin.py Wed Jul 3 02:16:08 2002 *************** *** 287,296 **** 'Go to the general list information page')) otherlinks.AddItem(Link(mlist.GetScriptURL('edithtml'), 'Edit the HTML for the public list pages')) ! otherlinks.AddItem(Link(mlist.GetBaseArchiveURL(), 'Go to list archives')) ! otherlinks.AddItem(Link('%s/logout' % adminurl, ! # TBD: What I really want is a blank line :/ ! 'Logout')) categorylinks = UnorderedList() for k, v in CATEGORIES: --- 287,295 ---- 'Go to the general list information page')) otherlinks.AddItem(Link(mlist.GetScriptURL('edithtml'), 'Edit the HTML for the public list pages')) ! otherlinks.AddItem(Link(mlist.GetBaseArchiveURL(), ! 'Go to list archives
       
      ')) ! otherlinks.AddItem(Link('%s/logout' % adminurl, 'Logout')) categorylinks = UnorderedList() for k, v in CATEGORIES: ---------------------- multipart/mixed attachment-- From alan@batie.org Wed Jul 3 10:25:17 2002 From: alan@batie.org (Alan Batie) Date: Wed, 3 Jul 2002 02:25:17 -0700 Subject: [Mailman-Developers] Re: Discard patch In-Reply-To: <20020703022225.A65576@agora.rdrop.com> References: <20020703022225.A65576@agora.rdrop.com> Message-ID: <20020703022517.A68128@agora.rdrop.com> PS: The patches are for 2.0.12... and I just realized I did them from subdirectories. Sorry about that... if you a new diff from the top, let me know. I'm going to bed now ;-) -- Alan Batie ______ www.rdrop.com/users/alan Me alan@batie.org \ / www.qrd.org The Triangle PGPFP DE 3C 29 17 C0 49 7A \ / www.pgpi.com The Weird Numbers 27 40 A5 3C 37 4A DA 52 B9 \/ razor.sourceforge.net NO SPAM! A free society is a place where it's safe to be unpopular. -Adlai Stevenson, statesman (1900-1965) From fil@rezo.net Wed Jul 3 15:34:44 2002 From: fil@rezo.net (Fil) Date: Wed, 3 Jul 2002 16:34:44 +0200 Subject: [Mailman-Developers] quite a few problems with current cvs In-Reply-To: <20020703091614.GA9709@rezo.net> References: <20020702155446.GA1971@rezo.net> <15650.33784.871959.802697@anthem.wooz.org> <20020703091614.GA9709@rezo.net> Message-ID: <20020703143444.GA13724@rezo.net> Dear Barry, I did a clean install from scratch, and the problem of no-confirm-by-email disappeared. Strangely, I could not see any difference between my two installations, but I might have not seen something. So we're left with this accentuated subjects problem, which is IMHO linked to a bad install of the email package. i'll wait for the next version ;-) -- Fil From barry@zope.com Wed Jul 3 16:59:12 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 3 Jul 2002 11:59:12 -0400 Subject: [Mailman-Developers] quite a few problems with current cvs References: <20020702155446.GA1971@rezo.net> <15650.33784.871959.802697@anthem.wooz.org> <20020703091614.GA9709@rezo.net> <20020703143444.GA13724@rezo.net> Message-ID: <15651.8016.48362.775566@anthem.wooz.org> >>>>> "F" == Fil writes: F> I did a clean install from scratch, and the problem of F> no-confirm-by-email disappeared. Strangely, I could not see any F> difference between my two installations, but I might have not F> seen something. Phew! 'Cause I still couldn't reproduce it. :) F> So we're left with this accentuated subjects problem, which is F> IMHO linked to a bad install of the email package. i'll wait F> for the next version ;-) Ok. I need to do a little more work on email before I tag it and update Mailman. Stay tuned. -Barry From fil@rezo.net Wed Jul 3 17:29:16 2002 From: fil@rezo.net (Fil) Date: Wed, 3 Jul 2002 18:29:16 +0200 Subject: [Mailman-Developers] =?iso-8859-1?Q?an?= =?iso-8859-1?Q?_accents_problem_with_=22=E9=22?= In-Reply-To: <15651.9110.824024.416555@anthem.wooz.org> References: <15649.54263.722207.93009@anthem.wooz.org> <20020702162836.GB8751@rezo.net> <20020702163140.GE8751@rezo.net> <15649.56799.12552.273761@anthem.wooz.org> <20020702203326.GA24512@rezo.net> <15650.36600.565124.969268@anthem.wooz.org> <20020703070504.GA27232@rezo.net> <15651.7626.412478.781301@anthem.wooz.org> <20020703161243.GE17358@rezo.net> <15651.9110.824024.416555@anthem.wooz.org> Message-ID: <20020703162916.GC24474@rezo.net> @ Barry A. Warsaw : > F> Yup, that's it : it's bogus in qfiles/in/ already. Thanks a lot > F> ! > > Yay! (Sorry. :). I'm not sure what's "bogus" and what's not "bogus". If the message arrives correctly iso-xxx encoded, Mailman should not double-encode it, isn't it? So let's see it better: mail test@rezo.net -s'יא' < .toprc gives, in qfiles/in, the following headers (correct) From fil@miel.brainstorm.fr Wed Jul 3 18:20:17 2002 Return-Path: Received: by miel.brainstorm.fr (Postfix, from userid 1001) id 8C5F51C4ED; Wed, 3 Jul 2002 18:20:17 +0200 (CEST) To: test@rezo.net Subject: יא Message-Id: <20020703162017.8C5F51C4ED@miel.brainstorm.fr> Date: Wed, 3 Jul 2002 18:20:17 +0200 (CEST) From: fil@miel.brainstorm.fr (Fil) then the same command line with 'mutt' gives From fil@miel.brainstorm.fr Wed Jul 3 18:22:07 2002 Return-Path: Received: by miel.brainstorm.fr (Postfix, from userid 1001) id 6703F1C4ED; Wed, 3 Jul 2002 18:22:07 +0200 (CEST) Date: Wed, 3 Jul 2002 18:22:07 +0200 From: Fil To: test@rezo.net Subject: =?iso-8859-1?B?6eA=?= Message-ID: <20020703162207.GA25625@rezo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.3.27i Is that correct or bogus ? It's encoded for sure, but seems correct. Does Mailman re-encode it? Let's see... bin/qrunner -r IncomingRunner -o In qfiles/out/ I find the bogus double-encoded thing in a pck file : # bin/dumpdb qfiles/out/1025713327.67135+2d30c5ab877e5544dcc801d067d9a61a1a0535b6.pck From fil@miel.brainstorm.fr Wed Jul 3 18:22:07 2002 Return-Path: Received: by miel.brainstorm.fr (Postfix, from userid 1001) id 6703F1C4ED; Wed, 3 Jul 2002 18:22:07 +0200 (CEST) Date: Wed, 3 Jul 2002 18:22:07 +0200 From: Fil To: test@rezo.net Message-ID: <20020703162207.GA25625@rezo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.3.27i Subject: =?iso-8859-1?q?=5BTest=5D_?= =?iso-8859-1?q?=3D=3Fiso-8859-1=3FB=3F6eA=3D=3F=3D?= X-BeenThere: test@rezo.net X-Mailman-Version: 2.1b2+ Precedence: list List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , So I'm not sure what to think. (Just to joke, I'm adding a bad character to th subject line of this post) -- Fil From barry@zope.com Wed Jul 3 17:44:54 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 3 Jul 2002 12:44:54 -0400 Subject: [Mailman-Developers] =?iso-8859-1?Q?an?= =?iso-8859-1?Q?_accents_problem_with_=22=E9=22?= References: <15649.54263.722207.93009@anthem.wooz.org> <20020702162836.GB8751@rezo.net> <20020702163140.GE8751@rezo.net> <15649.56799.12552.273761@anthem.wooz.org> <20020702203326.GA24512@rezo.net> <15650.36600.565124.969268@anthem.wooz.org> <20020703070504.GA27232@rezo.net> <15651.7626.412478.781301@anthem.wooz.org> <20020703161243.GE17358@rezo.net> <15651.9110.824024.416555@anthem.wooz.org> <20020703162916.GC24474@rezo.net> Message-ID: <15651.10758.809767.369195@anthem.wooz.org> >>>>> "F" == Fil writes: F> gives, in qfiles/in, the following headers (correct) Then again, if I send a message to myself with a Subject: =?iso-8859-1?B?6eA=?= I see no double-encoding. You can see no double encoding in this message's subject too! -Barry From barry@zope.com Wed Jul 3 17:48:17 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 3 Jul 2002 12:48:17 -0400 Subject: [Mailman-Developers] =?iso-8859-1?Q?an?= =?iso-8859-1?Q?_accents_problem_with_=22=E9=22?= References: <15649.54263.722207.93009@anthem.wooz.org> <20020702162836.GB8751@rezo.net> <20020702163140.GE8751@rezo.net> <15649.56799.12552.273761@anthem.wooz.org> <20020702203326.GA24512@rezo.net> <15650.36600.565124.969268@anthem.wooz.org> <20020703070504.GA27232@rezo.net> <15651.7626.412478.781301@anthem.wooz.org> <20020703161243.GE17358@rezo.net> <15651.9110.824024.416555@anthem.wooz.org> <20020703162916.GC24474@rezo.net> Message-ID: <15651.10961.179811.613184@anthem.wooz.org> What's the value of your list's subject_prefix? -Barry From barry@zope.com Wed Jul 3 17:39:53 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 3 Jul 2002 12:39:53 -0400 Subject: [Mailman-Developers] =?iso-8859-1?Q?an?= =?iso-8859-1?Q?_accents_problem_with_=22=E9=22?= References: <15649.54263.722207.93009@anthem.wooz.org> <20020702162836.GB8751@rezo.net> <20020702163140.GE8751@rezo.net> <15649.56799.12552.273761@anthem.wooz.org> <20020702203326.GA24512@rezo.net> <15650.36600.565124.969268@anthem.wooz.org> <20020703070504.GA27232@rezo.net> <15651.7626.412478.781301@anthem.wooz.org> <20020703161243.GE17358@rezo.net> <15651.9110.824024.416555@anthem.wooz.org> <20020703162916.GC24474@rezo.net> Message-ID: <15651.10457.426961.633356@anthem.wooz.org> >>>>> "F" == Fil writes: F> Is that correct or bogus ? It's encoded for sure, but seems F> correct. Does Mailman re-encode it? Let's see... bin/qrunner F> -r IncomingRunner -o I think it's correct. F> So I'm not sure what to think. (Just to joke, I'm adding a bad F> character to th subject line of this post) I'd classify this as a bug in email or in the way Mailman uses email. The original headers should be decoded from a string to an email.Header.Header instance. I'll try to work out the details of the bug and a patch. -Barry From fil@rezo.net Wed Jul 3 17:50:42 2002 From: fil@rezo.net (Fil) Date: Wed, 3 Jul 2002 18:50:42 +0200 Subject: [Mailman-Developers] =?iso-8859-1?Q?an?= =?iso-8859-1?Q?_accents_problem_with_=22=E9=22?= In-Reply-To: <15651.10758.809767.369195@anthem.wooz.org> References: <20020702163140.GE8751@rezo.net> <15649.56799.12552.273761@anthem.wooz.org> <20020702203326.GA24512@rezo.net> <15650.36600.565124.969268@anthem.wooz.org> <20020703070504.GA27232@rezo.net> <15651.7626.412478.781301@anthem.wooz.org> <20020703161243.GE17358@rezo.net> <15651.9110.824024.416555@anthem.wooz.org> <20020703162916.GC24474@rezo.net> <15651.10758.809767.369195@anthem.wooz.org> Message-ID: <20020703165042.GG24474@rezo.net> @ Barry A. Warsaw : > I see no double-encoding. You can see no double encoding in this > message's subject too! We ought to compare what's in the qfiles/in/ directory. If it's the same in both installations, but is spitted out bad by mine and correctly by yours, it must be in 'email' (or in the way Mailman calls 'email'). Am I right? -- Fil From fil@rezo.net Wed Jul 3 17:52:30 2002 From: fil@rezo.net (Fil) Date: Wed, 3 Jul 2002 18:52:30 +0200 Subject: [Mailman-Developers] =?iso-8859-1?Q?an?= =?iso-8859-1?Q?_accents_problem_with_=22=E9=22?= In-Reply-To: <15651.10961.179811.613184@anthem.wooz.org> References: <20020702163140.GE8751@rezo.net> <15649.56799.12552.273761@anthem.wooz.org> <20020702203326.GA24512@rezo.net> <15650.36600.565124.969268@anthem.wooz.org> <20020703070504.GA27232@rezo.net> <15651.7626.412478.781301@anthem.wooz.org> <20020703161243.GE17358@rezo.net> <15651.9110.824024.416555@anthem.wooz.org> <20020703162916.GC24474@rezo.net> <15651.10961.179811.613184@anthem.wooz.org> Message-ID: <20020703165230.GH24474@rezo.net> @ Barry A. Warsaw : > What's the value of your list's subject_prefix? For all lists tested It's something like [test] or [spip]. Let's make sure: mailman@miel:~$ bin/dumpdb lists/test/config.pck | grep prefix 'subject_prefix': '[Test] ', mailman@miel:~$ bin/dumpdb lists/spip/config.pck | grep prefix 'subject_prefix': '[Spip] ', -- Fil From barry@zope.com Wed Jul 3 18:04:21 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 3 Jul 2002 13:04:21 -0400 Subject: [Mailman-Developers] =?iso-8859-1?Q?an?= =?iso-8859-1?Q?_accents_problem_with_=22=E9=22?= References: <20020702163140.GE8751@rezo.net> <15649.56799.12552.273761@anthem.wooz.org> <20020702203326.GA24512@rezo.net> <15650.36600.565124.969268@anthem.wooz.org> <20020703070504.GA27232@rezo.net> <15651.7626.412478.781301@anthem.wooz.org> <20020703161243.GE17358@rezo.net> <15651.9110.824024.416555@anthem.wooz.org> <20020703162916.GC24474@rezo.net> <15651.10758.809767.369195@anthem.wooz.org> <20020703165042.GG24474@rezo.net> Message-ID: <15651.11925.187138.250005@anthem.wooz.org> >>>>> "F" =3D=3D Fil writes: >> I see no double-encoding. You can see no double encoding in >> this message's subject too! F> We ought to compare what's in the qfiles/in/ directory. If it's F> the same in both installations, but is spitted out bad by mine F> and correctly by yours, it must be in 'email' (or in the way F> Mailman calls 'email'). Am I right? Yes. Let's start from a common starting point so we can eliminate other tools. I'm using Python 2.2 here, and the following script to inject the message into a mailing list: -------------------- snip snip -------------------- import smtplib MAILHOST =3D 'localhost' MAILPORT =3D 25 MYLIST =3D 'CHANGEME' ME =3D 'CHANGEME' s =3D smtplib.SMTP() s.connect(MAILHOST, MAILPORT) s.sendmail(ME, [MYLIST], '''\ To: %s Subject: =3D?iso-8859-1?B?6eA=3D?=3D From: %s MIME-Version: 1.0 Content-Type: text/plain; charset=3Diso-8859-1 Content-Transfer-Encoding: 7bit =A1=A2=A3=A4=A5=A6=A7=A8=A9 =AA=AB=AC=AD=AE=AF=B0=B1=B2=B3 =B4=B5=B6=B7=B8=B9=BA=BB=BC=BD=BE =BF=C0=C1=C2=C3=C4=C5=C6 =C7=C8=C9=CA=CB=CC=CD=CE=CF =D0=D1=D2=D3=D4=D5=D6=D7 =D8=D9=DA=DB=DC=DD=DE=DF =E0=E1=E2=E3=E4=E5=E6=E7 =E8=E9=EA=EB=EC=ED=EE=EF =F0=F1=F2=F3=F4=F5=F6=F7 =F8=F9=FA=FB=FC=FD=FE=FF ''' % (MYLIST, ME)) s.close() -------------------- snip snip -------------------- So I run this and I end up with a message in my qfiles/in with the following Subject: Subject: =3D?iso-8859-1?B?6eA=3D?=3D Now I run "bin/qrunner -o -r Incoming" once and I end up with files in qfiles/archive (ignore these) and two in qfiles/out. bin/dumpdb on the qfiles/out/*.pck file and I get the following Subject: header: Subject: [Postal] =3D?iso-8859-1?B?6eA=3D?=3D Just as I expected. Now run "bin/qrunner -o -r Outgoing", the message disappears from my queue and shows up in my inbox, with the exact same Subject: as expected. What happens for you? -Barry From fil@rezo.net Wed Jul 3 18:14:21 2002 From: fil@rezo.net (Fil) Date: Wed, 3 Jul 2002 19:14:21 +0200 Subject: [Mailman-Developers] =?iso-8859-1?Q?an?= =?iso-8859-1?Q?_accents_problem_with_=22=E9=22?= In-Reply-To: <15651.11925.187138.250005@anthem.wooz.org> References: <20020702203326.GA24512@rezo.net> <15650.36600.565124.969268@anthem.wooz.org> <20020703070504.GA27232@rezo.net> <15651.7626.412478.781301@anthem.wooz.org> <20020703161243.GE17358@rezo.net> <15651.9110.824024.416555@anthem.wooz.org> <20020703162916.GC24474@rezo.net> <15651.10758.809767.369195@anthem.wooz.org> <20020703165042.GG24474@rezo.net> <15651.11925.187138.250005@anthem.wooz.org> Message-ID: <20020703171421.GC28604@rezo.net> @ Barry A. Warsaw : > So I run this and I end up with a message in my qfiles/in with the > following Subject: > > Subject: =?iso-8859-1?B?6eA=?= Yes, I have the same: To: test@rezo.net Subject: =?iso-8859-1?B?6eA=?= From: fil@rezo.net > Now I run "bin/qrunner -o -r Incoming" once and I end up with files in > qfiles/archive (ignore these) and two in qfiles/out. bin/dumpdb on > the qfiles/out/*.pck file and I get the following Subject: header: > > Subject: [Postal] =?iso-8859-1?B?6eA=?= I have: Subject: =?iso-8859-1?q?=5BTest=5D_?= =?iso-8859-1?q?=3D=3Fiso-8859-1=3FB=3F6eA=3D=3F=3D?= > Now run "bin/qrunner -o -r Outgoing", the message disappears from my > queue and shows up in my inbox, with the exact same Subject: as > expected. In the mutt pane : 4 N F 03/07 To test@rezo.net ( 11) [Test] =?iso-8859-1?B?6eA=?= When I "e"dit file to see its binary mood: Subject: =?iso-8859-1?q?=5BTest=5D_?= =?iso-8859-1?q?=3D=3Fiso-8859-1=3FB=3F6eA=3D=3F=3D?= ugly ! -- Fil From noreply@sourceforge.net Wed Jul 3 19:53:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jul 2002 11:53:40 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-425121 ] Double moderator approval messages Message-ID: Bugs item #425121, was opened at 2001-05-18 04:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=425121&group_id=103 Category: mail delivery >Group: 2.0.x >Status: Closed Resolution: None Priority: 4 Submitted By: Gert Jan Kruizinga (gjk4all) Assigned to: Thomas Wouters (twouters) Summary: Double moderator approval messages Initial Comment: Dear *, I get the message "Your message to Gein awaits moderator approval" two or three times after posting a message to the mailing list. My moderator also receives his message two or three times, but the two are not related to each other. I already tried to upgrade from mailman-2.0.1 to mailman-2.0.5, but the multiple posting still exists. I have not fount anything regarding this problem in the faq's so i submit it here. Gert Jan Kruizinga. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-03 14:53 Message: Logged In: YES user_id=12800 Since I haven't heard anything more about this, I'll assume an upgrade fixed your problem. Closing this bug report. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-04-28 18:07 Message: Logged In: YES user_id=12800 Is this bug still a problem for you? If so, first, I would recommend upgrading to MM2.0.10. Second, I'd like to know what version of Python you're using, and also what MTA (and version) you're using. If this is not a problem any more, please follow up so I can close this bug. ---------------------------------------------------------------------- Comment By: J. Ros (ros005) Date: 2002-01-14 09:35 Message: Logged In: YES user_id=414801 Yes, there are two different list admin accounts, but this is not the issue, as also regular users receive more than once. Most of the time I and all other users receive one copy of the mail, but sometimes this can be two, three or even four copies. It seems that mailman works fine most of the time, but sometimes it sends two (or more)copies of the same message. All types of message are affected, not only administrative messages of Mailman to the moderator or users, but also regular posts to members. I will include both message headers for a double message. Futhermore I will include the errors in the mailman log files for these messages. First message 10:02 Received: from sat-relay1.telecom.ptt.nl (sat- relay1.pc.telecom.ptt.nl [10.1.88.11]) by tmail050s.telecom.ptt.nl with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YJKFRJDJ; Fri, 11 Jan 2002 10:02:17 +0100 Received: from hdiro004.kpn.com (hdiro004.kpn.com [145.7.200.4]) by sat-relay1.telecom.ptt.nl (8.11.6/8.11.6) with SMTP id g0B92Kj21854; Fri, 11 Jan 2002 10:02:20 +0100 Received: from 145.7.200.6 by hdiro004.kpn.com (InterScan E- Mail VirusWall NT); Fri, 11 Jan 2002 10:02:20 +0100 Received: from mail.gjk4all.net (mail.gjk4all.net [213.196.2.118]) by relay1.kpn-telecom.nl (8.11.6/8.11.6) with ESMTP id g0B92JX02559; Fri, 11 Jan 2002 10:02:19 +0100 Received: from mail.gjk4all.net (mail.gjk4all.net [213.196.2.118]) by mail.gjk4all.net (Postfix) with ESMTP id BFE827C90; Fri, 11 Jan 2002 10:02:16 +0100 (CET) Received: by mail.gjk4all.net (Postfix, from userid 1011) id EB3D77C8C; Fri, 11 Jan 2002 10:00:28 +0100 (CET) Content-Type: Multipart/Related; boundary="---------- =_1010739627-91125-0" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) To: gein@gjk4all.net Message-Id: <20020111090028.EB3D77C8C@mail.gjk4all.net> From: gein-admin@gjk4all.net Reply-To: gein@gjk4all.net Subject: [Gein] Dagelijkse portie fokke en sukke Sender: gein-admin@gjk4all.net Errors-To: gein-admin@gjk4all.net X-BeenThere: gein@mail.gjk4all.net X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 10:00:28 +0100 (CET) This is a multi-part message in MIME format... ------------=_1010739627-91125-0 Content-Type: Text/HTML Content-Disposition: inline Content-Transfer-Encoding: binary Content-Id: Part-1-20020111@ ------------=_1010739627-91125-0 Content-Type: image/gif; name="fokke_sukke_20020111.gif" Content-Disposition: inline; filename="fokke_sukke_20020111.gif" Content-Transfer-Encoding: base64 Content-Id: Part-2-20020111@ ------------=_1010739627-91125-0-- =========================================== Second message 10:03 Received: from sat-relay1.telecom.ptt.nl (sat- relay1.pc.telecom.ptt.nl [10.1.88.11]) by tmail050s.telecom.ptt.nl with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YJKFRJDY; Fri, 11 Jan 2002 10:02:27 +0100 Received: from hdiro004.kpn.com (hdiro004.kpn.com [145.7.200.4]) by sat-relay1.telecom.ptt.nl (8.11.6/8.11.6) with SMTP id g0B92Uj21921; Fri, 11 Jan 2002 10:02:30 +0100 Received: from 145.7.200.7 by hdiro004.kpn.com (InterScan E- Mail VirusWall NT); Fri, 11 Jan 2002 10:02:30 +0100 Received: from mail.gjk4all.net (mail.gjk4all.net [213.196.2.118]) by relay2.kpn-telecom.nl (8.11.6/8.11.6) with ESMTP id g0B92Tv07835; Fri, 11 Jan 2002 10:02:29 +0100 Received: from mail.gjk4all.net (mail.gjk4all.net [213.196.2.118]) by mail.gjk4all.net (Postfix) with ESMTP id 8C63C7F9A; Fri, 11 Jan 2002 10:02:28 +0100 (CET) Received: by mail.gjk4all.net (Postfix, from userid 1011) id D42257C9A; Fri, 11 Jan 2002 10:00:28 +0100 (CET) Content-Type: Multipart/Related; boundary="---------- =_1010739627-91125-0" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) To: gein@gjk4all.net Message-Id: <20020111090028.D42257C9A@mail.gjk4all.net> From: gein-admin@gjk4all.net Reply-To: gein@gjk4all.net Subject: [Gein] Dagelijkse portie fokke en sukke Sender: gein-admin@gjk4all.net Errors-To: gein-admin@gjk4all.net X-BeenThere: gein@mail.gjk4all.net X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 10:00:28 +0100 (CET) This is a multi-part message in MIME format... ------------=_1010739627-91125-0 Content-Type: Text/HTML Content-Disposition: inline Content-Transfer-Encoding: binary Content-Id: Part-1-20020111@ ------------=_1010739627-91125-0 Content-Type: image/gif; name="fokke_sukke_20020111.gif" Content-Disposition: inline; filename="fokke_sukke_20020111.gif" Content-Transfer-Encoding: base64 Content-Id: Part-2-20020111@ ------------=_1010739627-91125-0-- ==================================== Errors: error:Jan 11 10:02:15 2002 qrunner(91278): Traceback (most recent call last): error:Jan 11 10:02:15 2002 qrunner(91278): File "/usr/local/mailman/Mailman/Archiver/Archiver.py", line 213, in ArchiveMail error:Jan 11 10:02:15 2002 qrunner(91278): self.ExternalArchive(mm_cfg.PUBLIC_EXTERNAL_ARCHIVER, txt) error:Jan 11 10:02:15 2002 qrunner(91278): File "/usr/local/mailman/Mailman/Archiver/Archiver.py", line 174, in ExternalArchive error:Jan 11 10:02:15 2002 qrunner(91278): syslog ('error', 'external archiver non-zero exit status: %d\n' % error:Jan 11 10:02:15 2002 qrunner(91278): TypeError: bad operand type(s) for >> error:Jan 11 10:02:15 2002 (91278) CORRUPT ARCHIVE FOR LIST: gein error:Jan 11 10:02:27 2002 qrunner(91278): Traceback (most recent call last): error:Jan 11 10:02:27 2002 qrunner(91278): File "/usr/local/mailman/Mailman/Archiver/Archiver.py", line 213, in ArchiveMail error:Jan 11 10:02:27 2002 qrunner(91278): self.ExternalArchive(mm_cfg.PUBLIC_EXTERNAL_ARCHIVER, txt) error:Jan 11 10:02:27 2002 qrunner(91278): File "/usr/local/mailman/Mailman/Archiver/Archiver.py", line 174, in ExternalArchive error:Jan 11 10:02:27 2002 qrunner(91278): syslog ('error', 'external archiver non-zero exit status: %d\n' % error:Jan 11 10:02:27 2002 qrunner(91278): TypeError: bad operand type(s) for >> error:Jan 11 10:02:27 2002 (91278) CORRUPT ARCHIVE FOR LIST: gein post:Jan 11 10:02:23 2002 (91278) post to gein from gein- admin@mail.gjk4all.net, size=12424, success post:Jan 11 10:02:36 2002 (91278) post to gein from gein- admin@mail.gjk4all.net, size=12424, success qrunner:Jan 11 10:02:00 2002 (91278) Exception reading qfile: /usr/local/mailman/qfiles/2e3744b0aa565e294e50cc52632 bb41cb439b904 qrunner:Jan 11 10:02:00 2002 (91278) Exception reading qfile: /usr/local/mailman/qfiles/3142c3521506e1863bcab1aaab4 eb9b00b556d90 qrunner:Jan 11 10:02:00 2002 (91278) Exception reading qfile: /usr/local/mailman/qfiles/35bd0398c386c9fa5949935d920 6517d6bff0e35 qrunner:Jan 11 10:02:00 2002 (91278) Exception reading qfile: /usr/local/mailman/qfiles/871f29104cec59a6c8046bc8a9e bf3047fa800b6 qrunner:Jan 11 10:02:00 2002 (91278) Exception reading qfile: /usr/local/mailman/qfiles/c0e97e9812d06e3e9eb47b29f18 1c26da7dbf6cc qrunner:Jan 11 10:02:00 2002 (91278) Exception reading qfile: /usr/local/mailman/qfiles/5f20c0dcd3c3a96ff32df4fe272 52589a93c8cbb qrunner:Jan 11 10:02:00 2002 (91278) Exception reading qfile: /usr/local/mailman/qfiles/e71a75f4429e10b4a8befe6f429 48d0a5f8d4fcd smtp:Jan 11 10:02:20 2002 (91278) smtp for 28 recips, completed in 4.455 seconds smtp:Jan 11 10:02:36 2002 (91278) smtp for 28 recips, completed in 8.968 seconds ---------------------------------------------------------------------- Comment By: J. Ros (ros005) Date: 2001-12-31 13:00 Message: Logged In: YES user_id=414801 Hi, I am the listadmin of gjk4all. We still have the same problem. Messages get sent more than once. This means not only administrative messages of Mailman to the moderator or users, but also regular posts to menmbers. I noticed the same problem on a different mailing list I am subscribed to: http://www.giggleshumor.com The problem seems to be related to the time of day. I hope you can find a solution. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-06-04 14:41 Message: Logged In: YES user_id=12800 In order to debug this, I would need a copy of the all duplicates for one of the duplicated messages. Please include /all/ the original headers, as that's the only way to determine what's going on. My suspicion is that there are multiple qrunners running, and that they aren't getting locked out correctly for some reason. Clearly, we have not seen similar bugs for MM2.0.5 on {python,zope}.org, so I expect it to be a configuration problem. ---------------------------------------------------------------------- Comment By: Gert Jan Kruizinga (gjk4all) Date: 2001-05-29 10:14 Message: Logged In: YES user_id=222418 No, all the users of the list also get the `"your message awaits moderator approval" message twice. Btw i'm not the listadmin, only the server admin, my listadmin also complains that he gets the "messages awaiting moderator approval" message sometimes 2, 3 or even 4 times, but he submitted two email addresses of his own, so that can be explaind. Gert Jan Kruizinga. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-05-29 09:56 Message: Logged In: YES user_id=34209 Are you sure you aren't listed as the list-admin several times ? Do you get each messages that many times ? What about the message headers: can you see where they get 'duplicated' ? (Compare Received: lines and message-id's between the duplicates to find out.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=425121&group_id=103 From noreply@sourceforge.net Wed Jul 3 19:55:17 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 03 Jul 2002 11:55:17 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-572312 ] bin/update fails on bogus import Message-ID: Bugs item #572312, was opened at 2002-06-21 17:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=572312&group_id=103 Category: configuring/installing Group: 2.1 beta >Status: Closed Resolution: None Priority: 5 Submitted By: Larry A. Price (swirly) Assigned to: Nobody/Anonymous (nobody) Summary: bin/update fails on bogus import Initial Comment: Traceback (most recent call last): File "bin/update", line 47, in ? from Mailman import MailList File "/var/lib/mailman/Mailman/MailList.py", line 40, in ? from email.Utils import getaddresses, formataddr, parseaddr ImportError: cannot import name formataddr make: *** [update] Error 1 there is no function formataddr in /usr/lib/python2.2/email/Utils.py formataddr is called only within the code to generate the admin_notif for new subscriptions. My solution was 40c40 < from email.Utils import getaddresses, formataddr, parseaddr --- > from email.Utils import getaddresses, parseaddr 865c865 < "member" : formataddr((name, email)), --- > "member" : "%s <%s>" % (name, email), ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-03 14:55 Message: Logged In: YES user_id=12800 The next Mailman beta will fix this by installing it's own copy of the email package instead of trying to use the (incomplete) one from Python 2..2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=572312&group_id=103 From noreply@sourceforge.net Thu Jul 4 09:13:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jul 2002 01:13:30 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-540978 ] eMailadress too long ? Message-ID: Bugs item #540978, was opened at 2002-04-08 14:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=540978&group_id=103 Category: mail delivery Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Markus Mandalka (mandalka) Assigned to: Nobody/Anonymous (nobody) Summary: eMailadress too long ? Initial Comment: I have a list antiatomforum@lists.kommunikationssystem.de and others with long names. It seems that mailman can not handle with such long names, because in the subscribe-mail (which you have to answer to be in the list) the first columns are some things from the header (unsubscribe: xxx@lists.xxx and so on). Whith names like atest@lists.kommunikationssystem.de it works. ---------------------------------------------------------------------- Comment By: Jean Millerat (drsigmund) Date: 2002-07-04 10:13 Message: Logged In: YES user_id=70686 I have reached the same bug with mailing list adresses such as <11 characters>@<30 characters> whereas <8 characters>@<30 characters> works properly. The effect of this bug is that the headers of the subcription annoucement or any further email from the list are "mangled" as was said on [mailman-developers]. As an example when one of the List-* header line is too long, it is broken in two parts (and the second part is indented). Since then, Outlook (and I suppose other email clients) think this second part of the broken header line is the beginning of the body of the message. Therefore the remaining headers are sent as part of the body of the message ! I think this bug does not only occur with too long email adresses but may occur with too long header lines whichever line it is (even with the Subject line especially when this subject line is very long because of quoted-printable characters). See [mailman-developers] for the description of maybe the same bug, in mails dealing with headers being "mangled". My current workarounds : - using short mailing list names. - and not sending quoted-printable characters within subject lines. ---------------------------------------------------------------------- Comment By: Giovanni Lopedote (giuans) Date: 2002-05-02 16:27 Message: Logged In: YES user_id=531451 I've found it. A fast fix for is to comment lines 149-150 in Mailman/Handlers:/CookHeaders.py: --- CookHeaders.py 2002-05-02 14:51:36.000000000 +0200 +++ CookHeaders.py.new 2002-05-02 16:12:09.000000000 +0200 @@ -146,8 +146,8 @@ # Wrap these lines if they are too long. 78 character width probably # shouldn't be hardcoded, but is at least text-MUA friendly. The # adding of 2 is for the colon-space separator. - if len(h) + 2 + len(v) > 78: - v = CONTINUATION.join(v.split(', ')) +# if len(h) + 2 + len(v) > 78: +# v = CONTINUATION.join(v.split(', ')) msg[h] = v # Always delete List-Archive header, but only add it back if the list is # actually archiving Tested with Mailman 2.1b1, Source Mage GNU/Linux 2.4.18, Postfix 1.1.7. I know there should be a better way, but I'm not a Python programmer at all. :) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-04-12 00:03 Message: Logged In: YES user_id=12800 I've confirmed this bug, but don't have a fix for it right now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=540978&group_id=103 From noreply@sourceforge.net Fri Jul 5 00:59:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 04 Jul 2002 16:59:52 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-577617 ] Edit before approve Message-ID: Bugs item #577617, was opened at 2002-07-04 23:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=577617&group_id=103 Category: Web/CGI Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Jasper van Beusekom (jvbeusek) Assigned to: Nobody/Anonymous (nobody) Summary: Edit before approve Initial Comment: All my list owners have made the mistake of expecting to be able to edit a message in the admindb interface before approving, assuming that the edited message would reach the list... I realize that the form-fields are truncated from the original message, but would there be some way for the owner to edit a message before approving it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=577617&group_id=103 From noreply@sourceforge.net Fri Jul 5 08:35:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Jul 2002 00:35:26 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-577685 ] sh syntax problem in configure Message-ID: Bugs item #577685, was opened at 2002-07-05 07:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=577685&group_id=103 Category: configuring/installing Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: sh syntax problem in configure Initial Comment: in 2.0.12 configure script includes a statement: if [ "$?" == "1" ] which should be in a traditional sh: if [ "$?" = "1" ] (Note single =, not double =) configure fails on solaris 8 with double =, while the error was ignored on FreeBSD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=577685&group_id=103 From fbaroni@axoadi.it Fri Jul 5 09:12:11 2002 From: fbaroni@axoadi.it (Gian Franco Baroni) Date: Fri, 5 Jul 2002 10:12:11 +0200 Subject: [Mailman-Developers] Error while installing 2.1b2 In-Reply-To: <15651.11925.187138.250005@anthem.wooz.org> Message-ID: I get this error during "make install" "Traceback (most recent call last): File "bin/update", line 44, in ? import paths ImportError: No module named paths make: *** [update] Error 1" Here is the config string:=20 ./configure --prefix=3D/home/mailman2 --with-python=3D/usr/bin/python2 = --with-mail-gid=3D12 --with-cgi-gid=3D48 No errors during configuration. Python is 2.2.1. Any idea? Thanks GFB From noreply@sourceforge.net Fri Jul 5 21:13:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 05 Jul 2002 13:13:12 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-577919 ] Forwarding to comma separated addresses Message-ID: Bugs item #577919, was opened at 2002-07-05 16:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=577919&group_id=103 Category: Web/CGI Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Pavel Roskin (proski) Assigned to: Nobody/Anonymous (nobody) Summary: Forwarding to comma separated addresses Initial Comment: Mailman 2.0.8 gives an option to forward mail held for approval. Entering comma separated addresses as the forwarding address doesn't cause any warnings, but the message is only delivered to the first address. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=577919&group_id=103 From marc_news@vasoftware.com Sat Jul 6 05:16:26 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Fri, 5 Jul 2002 21:16:26 -0700 Subject: [Mailman-Developers] Mailman-cvs can't handle .info addresses? Message-ID: <20020706041626.GC17029@merlins.org> I have someone who subscribed with a .info address to one of my lists, and I have VERP enabled. Apparently, mailman chokes on that (see the verp address, it's incorrect: it doesn't contain the list name). Does mailman use an out of date list of TLDs anywhere? ----- Forwarded message from mailman-owner@lists.merlins.org ----- Subject: Bounce action notification From: mailman-owner@lists.merlins.org To: sa-exim-owner@merlins.org X-List-Administrivia: yes This is a Mailman mailing list bounce action notice: List: SA-Exim Member: aly.dharshi@smail.info Action: Subscription disabled. Reason: Excessive or fatal bounces. The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman-owner@lists.merlins.org. From: MAILER-DAEMON@deep.smail.info (Mail Delivery System) To: sa-exim-bounces+aly.dharshi=smail.info@merlins.org X-WhitelistedRCPT-nohdrfromcallback: Yes Subject: Undelivered Mail Returned to Sender X-Spam-Status: No, hits=1.8 required=7.0 tests=NO_MX_FOR_FROM version=2.21 X-Spam-Level: * Content-Description: Notification This is the Postfix program at host deep.smail.info. I'm sorry to have to inform you that the message returned below could not be delivered to one or more destinations. For further assistance, please send mail to If you do so, please include this problem report. You can delete your own text from the message returned below. The Postfix program : host mail.merlins.org[204.80.101.251] said: 550-Verification failed for 550-Unrouteable address 550 Sender verify failed Content-Description: Delivery error report Reporting-MTA: dns; deep.smail.info Arrival-Date: Sat, 6 Jul 2002 07:14:24 +0400 (MSD) Final-Recipient: rfc822; aly.dharshi=smail.info@merlins.org Action: failed Status: 5.0.0 Diagnostic-Code: X-Postfix; host mail.merlins.org[204.80.101.251] said: 550-Verification failed for 550-Unrouteable address 550 Sender verify failed Content-Description: Undelivered Message Subject: You have been unsubscribed from the SA-Exim mailing list From: sa-exim-bounces@deep.smail.info To: aly.dharshi=smail.info@merlins.org, aly.dharshi@smail.info X-List-Administrivia: yes ----- End forwarded message ----- -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From noreply@sourceforge.net Sun Jul 7 08:26:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 07 Jul 2002 00:26:27 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-565917 ] mailmanctl bombs after unclean shutdown Message-ID: Bugs item #565917, was opened at 2002-06-07 18:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=565917&group_id=103 Category: command line scripts Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Dale Stimson (dstimson) Assigned to: Nobody/Anonymous (nobody) Summary: mailmanctl bombs after unclean shutdown Initial Comment: Environment: Red Hat 7.3, latest errata, Mailman 2.1b2 I see that this problem still exists in the current CVS as of a day or two ago. When mailman restarts after having been shutdown uncleanly (e.g., when rebooting following a crash), it bombs leaving no qrunners active with the following in the log: Jun 04 18:05:13 2002 mailmanctl(1572): Traceback (most recent call last): Jun 04 18:05:13 2002 mailmanctl(1572): File "/var/mailman/bin/mailmanctl", line 502, in ? Jun 04 18:05:13 2002 mailmanctl(1572): main() Jun 04 18:05:13 2002 mailmanctl(1572): File "/var/mailman/bin/mailmanctl", line 352, in main Jun 04 18:05:13 2002 mailmanctl(1572): lock = acquire_lock(force) Jun 04 18:05:13 2002 mailmanctl(1572): File "/var/mailman/bin/mailmanctl", line 203, in acquire_lock Jun 04 18:05:13 2002 mailmanctl(1572): lock = acquire_lock_1(force) Jun 04 18:05:13 2002 mailmanctl(1572): File "/var/mailman/bin/mailmanctl", line 197, in acquire_lock_1 Jun 04 18:05:13 2002 mailmanctl(1572): os.unlink(tempfile) Jun 04 18:05:13 2002 mailmanctl(1572): OSError : [Errno 2] No such file or directory: 'master-qrunner.cupro.opengvs.com.9014' Diagnosis: In file bin/mailmanctl, function acquire_lock_1 is attempting to delete the lock file left over from the last run. It calls function get_lock_data to find the name of the old lock file that is to be deleted. Function get_lock_data (incorrectly) returns the file name with the directory part of the path stripped, thereby causing the delete to fail and the trap to occur. Function get_lock_data should instead return the entire file path, including directories. The patch given below corrects the behavior of get_lock_data. As an aside, it would be nice if acquire_lock_1 was more forgiving if the os.unlink calls fail due to "no such file". I have not submitted a patch for that as I don't know the appropriate python semantics. ---------------------------------------------------------------------- Comment By: E. Viennet (anotong) Date: 2002-07-07 07:26 Message: Logged In: YES user_id=396722 I also observed this behavior. I did patch my mailman (mailmanctl, acquire_lock_1) by putting try/except pairs around each call to unlink(), but I'm not sure it's the correct fix. ---------------------------------------------------------------------- Comment By: Dale Stimson (dstimson) Date: 2002-06-07 18:14 Message: Logged In: YES user_id=559033 Please ignore uploaded file sf1.txt (it won't let me delete it), which has cruft in it (the problem report text), as opposed to just the patch). The file with just the patch is sf.txt. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=565917&group_id=103 From jarrell@vt.edu Sun Jul 7 13:58:19 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Sun, 07 Jul 2002 08:58:19 -0400 Subject: [Mailman-Developers] phantom moderation... Message-ID: <5.1.0.14.2.20020707085658.00a47510@mail.vt.edu> You know, the bug where mailman thinks that there's something to do in admindb, but there's really not, is slowly driving me and my listadmins mad... I'm getting about 7 mail messages a day now informing me that I still need to do something, when I know damn well I don't... From jarrell@vt.edu Sun Jul 7 14:12:40 2002 From: jarrell@vt.edu (Ron Jarrell) Date: Sun, 07 Jul 2002 09:12:40 -0400 Subject: [Mailman-Developers] Mailman-cvs can't handle .info addresses? In-Reply-To: <20020706041626.GC17029@merlins.org> Message-ID: <5.1.0.14.2.20020707090748.00a47180@lennier.cc.vt.edu> It's not wrong everywhere - the actual bounce from their mailer daemon mentions the correct verp address for your list, for instance. But look at the way it broke it up: >: host mail.merlins.org[204.80.101.251] > said: 550-Verification failed for > 550-Unrouteable address 550 Sender verify failed It looks like they tried to VRFY back at you that your sender existed, and either they broke it up at the +, or your VRFY can't cope with it, and so they decided not to deliver the mail because they think *you* don't exist... Notice that it says that mail.merlins.org is the one complaining, not them. They're the reporting host. At 09:16 PM 7/5/02 -0700, Marc MERLIN wrote: >I have someone who subscribed with a .info address to one of my lists, and I >have VERP enabled. >Apparently, mailman chokes on that (see the verp address, it's incorrect: it >doesn't contain the list name). Does mailman use an out of date list of TLDs >anywhere? > >----- Forwarded message from mailman-owner@lists.merlins.org ----- > >Subject: Bounce action notification >From: mailman-owner@lists.merlins.org >To: sa-exim-owner@merlins.org >X-List-Administrivia: yes > >This is a Mailman mailing list bounce action notice: > > List: SA-Exim > Member: aly.dharshi@smail.info > Action: Subscription disabled. > Reason: Excessive or fatal bounces. > > > >The triggering bounce notice is attached below. > >Questions? Contact the Mailman site administrator at >mailman-owner@lists.merlins.org. > >From: MAILER-DAEMON@deep.smail.info (Mail Delivery System) >To: sa-exim-bounces+aly.dharshi=smail.info@merlins.org >X-WhitelistedRCPT-nohdrfromcallback: Yes >Subject: Undelivered Mail Returned to Sender >X-Spam-Status: No, hits=1.8 required=7.0 > tests=NO_MX_FOR_FROM > version=2.21 >X-Spam-Level: * > >Content-Description: Notification >This is the Postfix program at host deep.smail.info. > >I'm sorry to have to inform you that the message returned >below could not be delivered to one or more destinations. > >For further assistance, please send mail to > >If you do so, please include this problem report. You can >delete your own text from the message returned below. > > The Postfix program > >: host mail.merlins.org[204.80.101.251] > said: 550-Verification failed for > 550-Unrouteable address 550 Sender verify failed > >Content-Description: Delivery error report >Reporting-MTA: dns; deep.smail.info >Arrival-Date: Sat, 6 Jul 2002 07:14:24 +0400 (MSD) > >Final-Recipient: rfc822; aly.dharshi=smail.info@merlins.org >Action: failed >Status: 5.0.0 >Diagnostic-Code: X-Postfix; host mail.merlins.org[204.80.101.251] said: > 550-Verification failed for > 550-Unrouteable address 550 Sender verify failed > >Content-Description: Undelivered Message >Subject: You have been unsubscribed from the SA-Exim mailing list >From: sa-exim-bounces@deep.smail.info >To: aly.dharshi=smail.info@merlins.org, aly.dharshi@smail.info >X-List-Administrivia: yes > > > > > > >----- End forwarded message ----- > >-- >"A mouse is a device used to point at the xterm you want to type in" - A.S.R. >Microsoft is to operating systems & security .... > .... what McDonalds is to gourmet > cooking >Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for >PGP key > > >_______________________________________________ >Mailman-Developers mailing list >Mailman-Developers@python.org >http://mail.python.org/mailman-21/listinfo/mailman-developers From marc_news@vasoftware.com Sun Jul 7 16:38:24 2002 From: marc_news@vasoftware.com (Marc MERLIN) Date: Sun, 7 Jul 2002 08:38:24 -0700 Subject: [Mailman-Developers] Mailman-cvs can't handle .info addresses? In-Reply-To: <5.1.0.14.2.20020707090748.00a47180@lennier.cc.vt.edu> References: <20020706041626.GC17029@merlins.org> <5.1.0.14.2.20020707090748.00a47180@lennier.cc.vt.edu> Message-ID: <20020707153824.GB27224@merlins.org> On Sun, Jul 07, 2002 at 09:12:40AM -0400, Ron Jarrell wrote: > It's not wrong everywhere - the actual bounce from their mailer daemon > mentions the correct verp address for your list, for instance. Mmmh, looking at it further, it looks like you're right. > But look at the way it broke it up: > >: host mail.merlins.org[204.80.101.251] > > said: 550-Verification failed for > > > > 550-Unrouteable address 550 Sender verify failed I got confused as to who was checking whom, but you're right, they have broken SMTP callback. 2002-07-05 20:15:25 H=smail.info (deep.smail.info) [193.165.168.18]:52108 sender verify fail for : Unrouteable address 2002-07-05 20:15:25 H=smail.info (deep.smail.info) [193.165.168.18]:52108 F= rejected RCPT : Sender verify failed What confuse(d/s) me, are the headers of the mail mailman supposedly sent: > >Content-Description: Undelivered Message > >Subject: You have been unsubscribed from the SA-Exim mailing list > >From: sa-exim-bounces@deep.smail.info > >To: aly.dharshi=smail.info@merlins.org, aly.dharshi@smail.info The To: just looks wrong > It looks like they tried to VRFY back at you that your sender existed, and Actually it's an SMTP callback. > exist... Notice that it says that mail.merlins.org is the one complaining, > not them. They're the reporting host. Yep, but I'm only complaining because the callback address is incorrect. They do a callback to aly.dharshi=smail.info@merlins.org, and if this was my envelope sender when I sent mail to them, it sure is incorrect. I'm still not convinced that there isn't a problem with my side, but there is something wrong with the other side first, so I'll start with that. 2002-07-05 20:15:25 H=smail.info (deep.smail.info) [193.165.168.18]:52108 sender verify fail for : Unrouteable address Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From fil@rezo.net Sun Jul 7 16:40:28 2002 From: fil@rezo.net (Fil) Date: Sun, 7 Jul 2002 17:40:28 +0200 Subject: [Mailman-Developers] phantom moderation... In-Reply-To: <5.1.0.14.2.20020707085658.00a47510@mail.vt.edu> References: <5.1.0.14.2.20020707085658.00a47510@mail.vt.edu> Message-ID: <20020707154028.GF25902@rezo.net> @ Ron Jarrell : > You know, the bug where mailman thinks that there's something to do in > admindb, but there's really not, is slowly driving me and my listadmins > mad... I'm getting about 7 mail messages a day now informing me that I > still need to do something, when I know damn well I don't... Well, try to have something to do ;-) More seriously, I have remarked that a very lowly sollicited list did not send this crazy message until then was actually one thing to do. Then, on each day after, I got the message. So the bug is not only when reading the list database : there might be corruption somewhere in the list database. This were my 2 cents -- if only it's worth that much. -- Fil From fil@rezo.net Sun Jul 7 17:00:06 2002 From: fil@rezo.net (Fil) Date: Sun, 7 Jul 2002 18:00:06 +0200 Subject: [Mailman-Developers] phantom moderation... In-Reply-To: <20020707154028.GF25902@rezo.net> References: <5.1.0.14.2.20020707085658.00a47510@mail.vt.edu> <20020707154028.GF25902@rezo.net> Message-ID: <20020707160006.GA28855@rezo.net> > Well, try to have something to do ;-) For example, one thing to do was to read the code. /usr/local/mailman/cron/checkdbs ******************************** try: count = mlist.NumRequestsPending() # While we're at it, let's evict yesterday's autoresponse data midnightToday = Utils.midnight() evictions = [] for sender in mlist.hold_and_cmd_autoresponses.keys(): - date, count = mlist.hold_and_cmd_autoresponses[sender] + date, xxxxx = mlist.hold_and_cmd_autoresponses[sender] We don't need the 'count = mlist.NumRequestsPending()' to be polluted by the 'count' of line 52. I've put xxxxx in place of 'count', and the bug disappears. Sure Barry will find something better than xxxx ;) -- Fil From westin@fas.harvard.edu Mon Jul 8 23:40:41 2002 From: westin@fas.harvard.edu (Greg Westin) Date: Mon, 8 Jul 2002 18:40:41 -0400 Subject: [Mailman-Developers] OSX installation problem - no "mailman" user Message-ID: I sent this question to the mailman-users list and got no response, so I thought maybe I should try here. I don't know if this is a problem because I'm a novice at these UNIX installations, or if there's something wrong with the Darwin installer: I'm trying to install Mailman on Mac OS X, and it's not working for me. For some reason, it keeps saying "no mailman user found" when I try to run configure... I've tried setting up said user in the System Preferences and in NetInfo. The user exists in the System Preferences, has a home directory, etc... but configure doesn't work. Do you have any ideas? Maybe I didn't enter some necessary things in NetInfo, or maybe something's not setgid'd right, or I don't know what. Thanks, Greg Westin westin@fas.harvard.edu From alan@batie.org Tue Jul 9 01:34:15 2002 From: alan@batie.org (Alan Batie) Date: Mon, 8 Jul 2002 17:34:15 -0700 Subject: [Mailman-Developers] OSX installation problem - no "mailman" user In-Reply-To: References: Message-ID: <20020708173415.B93616@agora.rdrop.com> On Mon, Jul 08, 2002 at 06:40:41PM -0400, Greg Westin wrote: > Maybe I didn't enter some necessary things in NetInfo, or > maybe something's not setgid'd right, or I don't know what. NetInfo is a holdover from the NextStep days and is a separate user database. Most likely, the mailman user is not in the /etc/passwd file that mailman is looking for. I'm not familiar enough with either mailman or OSX to say more than that, but I'm pretty sure that's the area to look in... -- Alan Batie ______ www.rdrop.com/users/alan Me alan@batie.org \ / www.qrd.org The Triangle PGPFP DE 3C 29 17 C0 49 7A \ / www.pgpi.com The Weird Numbers 27 40 A5 3C 37 4A DA 52 B9 \/ razor.sourceforge.net NO SPAM! A free society is a place where it's safe to be unpopular. -Adlai Stevenson, statesman (1900-1965) From bobb+mailman-developers@redbrick.dcu.ie Tue Jul 9 10:32:35 2002 From: bobb+mailman-developers@redbrick.dcu.ie (Robert Crosbie) Date: Tue, 9 Jul 2002 10:32:35 +0100 Subject: [Mailman-Developers] OSX installation problem - no "mailman" user In-Reply-To: <20020708173415.B93616@agora.rdrop.com> References: <20020708173415.B93616@agora.rdrop.com> Message-ID: <20020709093235.GA25628@lummux.tchpc.tcd.ie> Alan Batie hath declared on Monday the 08 day of July 2002 :-: > On Mon, Jul 08, 2002 at 06:40:41PM -0400, Greg Westin wrote: > > Maybe I didn't enter some necessary things in NetInfo, or > > maybe something's not setgid'd right, or I don't know what. > > NetInfo is a holdover from the NextStep days and is a separate user > database. Most likely, the mailman user is not in the /etc/passwd file > that mailman is looking for. I've only had limited experience with OSX, but I also had user related issues. /etc/passwd is apparently only used in single user mode. In multiuser, all applications query off the lookupd daemon, which gets its information from netinfo. The first thing I would suggest is to make sure that the username is _all lowercase_. I had this problem with sendmail, if you name a user with a "short name" of "John" and tried to send a mail to "john@domain.org" or "John@domain.org" it would bounce with "user unknown", however changing the "short name" from "John" to "john" made everything work, *sigh* I'm also not sure what the differance between the "name" and "short name" in netinfo is. It seemed to me that "short name" was comparable to your username and "name" was comparable to your gecos. I could be wrong, but, you might try putting "mailman" in as the "short name" Hope this helps... - bobb From noreply@sourceforge.net Tue Jul 9 21:16:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Jul 2002 13:16:48 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-579285 ] gate_news attempts connect to bad hosts Message-ID: Bugs item #579285, was opened at 2002-07-09 15:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=579285&group_id=103 Category: nntp/news Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Steve Fox (drfickle) Assigned to: Nobody/Anonymous (nobody) Summary: gate_news attempts connect to bad hosts Initial Comment: I've been having gate_news spew out 'Connection refused' errors every five minutes for quite some time now. I finally tracked down what the problem is, and hopefully someone more skilled in Python than I can create a simple fix. In the open_news function it doesn't check whether the mlist.nntp_host variable is valid or not (in my case it was a null string). A simple if check would solve the problem here, but I think that's addressing the symptom, not the problem. Rather I think the real problem is that the MailList class sets gateway_to_mail to "true" (I'm not sure what the real value is), even if the nntp host name is invalid. Then the process_lists function assumes that nntp_host is valid and calls open_newsgroup on it. I would suggest that if the nntp_host is invalid, that the MailList class not set gateway_to_mail to be "true". Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=579285&group_id=103 From noreply@sourceforge.net Tue Jul 9 21:32:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Jul 2002 13:32:49 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-579285 ] gate_news attempts connect to bad hosts Message-ID: Bugs item #579285, was opened at 2002-07-09 15:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=579285&group_id=103 Category: nntp/news Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Steve Fox (drfickle) Assigned to: Nobody/Anonymous (nobody) Summary: gate_news attempts connect to bad hosts Initial Comment: I've been having gate_news spew out 'Connection refused' errors every five minutes for quite some time now. I finally tracked down what the problem is, and hopefully someone more skilled in Python than I can create a simple fix. In the open_news function it doesn't check whether the mlist.nntp_host variable is valid or not (in my case it was a null string). A simple if check would solve the problem here, but I think that's addressing the symptom, not the problem. Rather I think the real problem is that the MailList class sets gateway_to_mail to "true" (I'm not sure what the real value is), even if the nntp host name is invalid. Then the process_lists function assumes that nntp_host is valid and calls open_newsgroup on it. I would suggest that if the nntp_host is invalid, that the MailList class not set gateway_to_mail to be "true". Thanks! ---------------------------------------------------------------------- >Comment By: Steve Fox (drfickle) Date: 2002-07-09 15:32 Message: Logged In: YES user_id=17512 I forgot to mention that gateway_to_mail seems to be set "true" anytime the mail-to-news page contains any non-default values. That is, even if hostname and newsgroup are blank, but one or more of the radio buttons are set to yes, gate_to_mail will be "true". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=579285&group_id=103 From noreply@sourceforge.net Tue Jul 9 22:16:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Jul 2002 14:16:59 -0700 Subject: [Mailman-Developers] [ mailman-Patches-534577 ] Add SpamAssassin filter to mail pipeline Message-ID: Patches item #534577, was opened at 2002-03-25 08:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=534577&group_id=103 Category: list administration Group: Mailman 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: Add SpamAssassin filter to mail pipeline Initial Comment: This filter adds support for discarding or holding spam sent to the mailing list. It contacts a spamd daemon (from SpamAssassin -- http://spamassassin.taint.org) to score the message. If the score is above a certain threshold (default 10), the message is discarded and an entry is written to the vette log. If the score is above another lower threshold (default 5), the message is held for moderation. The SpamAssassin.py file should be installed in Mailman/Handlers/. The LIST_PIPELINE variable in Mailman/Handlers/HandlerAPI.py should be modified to include a 'SpamAssassin' item (I put it just after the existing 'SpamDetect' item). To change the defaults, the following can be added to the mm_cfg.py file: SPAMASSASSIN_HOST = 'host:port' # how to contact SA SPAMASSASSIN_DISCARD_SCORE = 10 SPAMASSASSIN_HOLD_SCORE = 5 If you don't want to discard messages, then DISCARD_SCORE can be set to something very high (1000 should do it). It looks the MM2.1 filter APIs have changed a bit, so this filter will need some modifications to work with that version. When I get round to upgrading, I might look into updating it. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2002-07-09 21:16 Message: Logged In: YES user_id=81797 FYI, I ran the previous version since installation and it seemed to work fine. I didn't run into any problems, with probably 500 messages handled. I've updated to the new version and it seems ok so far, but I've only sent about 10 messages through. Sean ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-07-03 04:02 Message: Logged In: YES user_id=146903 Yet another version. There were some bugs in handling of certain error conditions when talking to spamd. These would result in exceptions and the messages staying in the delivery queue :( With the new version, the message will be passed through unchecked under these conditions, and a message will be added to the error log. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2002-06-12 21:48 Message: Logged In: YES user_id=81797 FYI: I've been running the 2002-05-14 version of this patch with spamassassin 2.20 for the last day on our main mailman box and it seems to be working great. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-05-14 06:04 Message: Logged In: YES user_id=146903 This version is essentially the same as the previous version, but adds compatibility with python > 1.5.2, which doesn't like you passing two arguments to socket.connect(). ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-04-27 06:17 Message: Logged In: YES user_id=146903 Just attached my updated version of the patch. This version requires SpamAssassin 2.20 (for the extra commands that the spamd daemon understands). It now displays a list of which rules were triggered for held messages, and can give messages from list members a bonus (defaults to 2), so that they are less likely to get held as spam. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-03-26 01:21 Message: Logged In: YES user_id=146903 There is a fairly easy optimisation for this filter that I missed when writing it. It calls str() on the message object twice. It would be quicker to call str() on the message once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=534577&group_id=103 From noreply@sourceforge.net Wed Jul 10 01:19:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Jul 2002 17:19:25 -0700 Subject: [Mailman-Developers] [ mailman-Patches-534577 ] Add SpamAssassin filter to mail pipeline Message-ID: Patches item #534577, was opened at 2002-03-25 16:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=534577&group_id=103 Category: list administration Group: Mailman 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: Add SpamAssassin filter to mail pipeline Initial Comment: This filter adds support for discarding or holding spam sent to the mailing list. It contacts a spamd daemon (from SpamAssassin -- http://spamassassin.taint.org) to score the message. If the score is above a certain threshold (default 10), the message is discarded and an entry is written to the vette log. If the score is above another lower threshold (default 5), the message is held for moderation. The SpamAssassin.py file should be installed in Mailman/Handlers/. The LIST_PIPELINE variable in Mailman/Handlers/HandlerAPI.py should be modified to include a 'SpamAssassin' item (I put it just after the existing 'SpamDetect' item). To change the defaults, the following can be added to the mm_cfg.py file: SPAMASSASSIN_HOST = 'host:port' # how to contact SA SPAMASSASSIN_DISCARD_SCORE = 10 SPAMASSASSIN_HOLD_SCORE = 5 If you don't want to discard messages, then DISCARD_SCORE can be set to something very high (1000 should do it). It looks the MM2.1 filter APIs have changed a bit, so this filter will need some modifications to work with that version. When I get round to upgrading, I might look into updating it. ---------------------------------------------------------------------- >Comment By: James Henstridge (jhenstridge) Date: 2002-07-10 08:19 Message: Logged In: YES user_id=146903 The Mailman installation on mail.gnome.org also uses this filter. I don't think there are any stability problems with the filter. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2002-07-10 05:16 Message: Logged In: YES user_id=81797 FYI, I ran the previous version since installation and it seemed to work fine. I didn't run into any problems, with probably 500 messages handled. I've updated to the new version and it seems ok so far, but I've only sent about 10 messages through. Sean ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-07-03 12:02 Message: Logged In: YES user_id=146903 Yet another version. There were some bugs in handling of certain error conditions when talking to spamd. These would result in exceptions and the messages staying in the delivery queue :( With the new version, the message will be passed through unchecked under these conditions, and a message will be added to the error log. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2002-06-13 05:48 Message: Logged In: YES user_id=81797 FYI: I've been running the 2002-05-14 version of this patch with spamassassin 2.20 for the last day on our main mailman box and it seems to be working great. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-05-14 14:04 Message: Logged In: YES user_id=146903 This version is essentially the same as the previous version, but adds compatibility with python > 1.5.2, which doesn't like you passing two arguments to socket.connect(). ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-04-27 14:17 Message: Logged In: YES user_id=146903 Just attached my updated version of the patch. This version requires SpamAssassin 2.20 (for the extra commands that the spamd daemon understands). It now displays a list of which rules were triggered for held messages, and can give messages from list members a bonus (defaults to 2), so that they are less likely to get held as spam. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-03-26 09:21 Message: Logged In: YES user_id=146903 There is a fairly easy optimisation for this filter that I missed when writing it. It calls str() on the message object twice. It would be quicker to call str() on the message once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=534577&group_id=103 From noreply@sourceforge.net Wed Jul 10 03:46:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 09 Jul 2002 19:46:05 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-555627 ] subject prefic encoding Message-ID: Bugs item #555627, was opened at 2002-05-13 14:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=555627&group_id=103 Category: mail delivery Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Norbert Bollow (bollow) Assigned to: Nobody/Anonymous (nobody) Summary: subject prefic encoding Initial Comment: In Mailman 2.1b2 on Python 2.1.3 with a mailing list that has German as its default language, the subject prefix gets encoded unneccessarily, e.g. [MNO] becomes =?iso-8859-1?q?=5BMNO=5D_?= . ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-07-09 19:46 Message: Logged In: NO It happens the same for mailman in spanish as default language, besides it reencode de original subject so one subject like: =?iso-8859-1?Q? prueba__no_leer:_el_parag=FCas=2C_el_cami=F3n_y_el_ni= F1o_?= becomes: =?iso-8859-1?q?=5BMON=5D_?= =?iso-8859-1?q?=3D=3Fiso-8859- 1=3FQ=3Fprueba=5F=5Fno=5Fleer=3A=5Fel=5Fpa?= =?iso-8859-1?q? rag=3DFCas=3D2C=5Fel=5Fcami=3DF3n=5Fy=5Fel=5Fni=3 DF1o=5F?= =?iso-8859-1?q?=3F=3D?= where it should be: =?iso-8859-1?q?=5BMON=5D_?= =?iso-8859-1?Q? prueba__no_leer:_el_parag=FCas=2C_el_cami=F3n_y_el_ni= F1o_?= or even: [MON] =?iso-8859-1?Q? prueba__no_leer:_el_parag=FCas=2C_el_cami=F3n_y_el_ni= F1o_?= why the incoming subject line (with the "subject :" part striped) isn't copied verbatim to the next line of the message sended? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=555627&group_id=103 From noreply@sourceforge.net Wed Jul 10 19:51:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jul 2002 11:51:06 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-565706 ] user wrongly detected Message-ID: Bugs item #565706, was opened at 2002-06-07 01:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=565706&group_id=103 Category: mail delivery Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Enrico Cherubini (bestkevin) Assigned to: Nobody/Anonymous (nobody) Summary: user wrongly detected Initial Comment: Hi, I'm using mailman 2.0.6 and a user, that is in the mailing list, is not able to write in it after I closed the list to members only. He is member as I can see in the members list, here is what happen: Jun 07 09:31:06 2002 (29505) post to lugvr from ., size=1350, success the poster is identified as '.'....here are headers of an email he sent: From: .::Spark::. If you need any further information you are welcome ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-07-10 11:51 Message: Logged In: NO Has the user turned off mail delivery? ---------------------------------------------------------------------- Comment By: Simone Piunno (pioppo) Date: 2002-06-07 01:43 Message: Logged In: YES user_id=227443 Ciao Enrico! did you remember me? I was pioppo on #linux-it @ IrcNET :) I think 1st of all you should upgrade to Mailman 2.0.11 and/or to a more recent Python (I guess you are using 1.5.2) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=565706&group_id=103 From noreply@sourceforge.net Thu Jul 11 01:53:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 10 Jul 2002 17:53:41 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-579908 ] Very poor configuration design Message-ID: Bugs item #579908, was opened at 2002-07-10 19:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=579908&group_id=103 Category: configuring/installing Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bob Tanner (tanner) Assigned to: Nobody/Anonymous (nobody) Summary: Very poor configuration design Initial Comment: The way configure is setup it seems to assume that you are building mailman ON the box you will be installing it. This is a terrible design decision. Make for creating packages a total nightmare. Forcing a package builder to add entries into /etc/passwd and /etc/group, is another bad design decision. Forcing a package builder to have all the directories setup and proper permissions during build it a another bad design decision. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=579908&group_id=103 From barry@zope.com Thu Jul 11 20:52:33 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 11 Jul 2002 15:52:33 -0400 Subject: [Mailman-Developers] RELEASED Mailman 2.0.12 Message-ID: <15661.57857.753290.942668@anthem.wooz.org> I' released Mailman 2.0.12 which fixes a cross-site scripting vulnerability, among other changes. I recommend that folks upgrade their 2.0.x systems to this new version. See below for a NEWS file excerpt. As usual, I've made both full source tarballs and patches available. See http://sourceforge.net/project/showfiles.php?group_id=103 for links to download all the patches and the source tarball. If you decide to install the patches, please do read the release notes first: http://sourceforge.net/project/shownotes.php?release_id=97760 See also: http://www.gnu.org/software/mailman http://www.list.org http://mailman.sf.net Cheers, -Barry -------------------- snip snip -------------------- 2.0.12 (02-Jul-2002) - Implemented a guard against some reply loops and 'bot subscription attacks. Specifically, if a message to -request has a Precedence: bulk (or list, or junk) header, the command is ignored. Well-behaved 'bots should always include such a header. - Changes to the configure script so that you can pass in the mail host and web host by setting the environment variables MAILHOST and WWWHOST respectively. configure will also exit if it can't figure out these values (usually due to broken dns). - Closed another minor cross-site scripting vulnerability. From alden@math.ohio-state.edu Wed Jul 10 18:22:29 2002 From: alden@math.ohio-state.edu (Dave Alden) Date: Wed, 10 Jul 2002 13:22:29 -0400 Subject: [Mailman-Developers] 2 pgms to assist in maintaining lists Message-ID: <20020710132229.A3146@math.ohio-state.edu> ---------------------- multipart/mixed attachment Hi, I've written 2 programs to help me maintain my mailing lists. The first I call "add_nonmembers". This program is based on add_members (I copied add_members to add_nonmembers and modified it :-). What it does is give me a simple command line interface to modifying the 4 options: accept_these_nonmembers hold_these_nonmembers reject_these_nonmembers discard_these_nonmembers 3 of my mailing lists are for the particular type of employee: faculty, grads and staff. I want anyone on any of the lists to be able to post to any of the lists. Under majordomo I could point their equivalent of "accept_these_nonmembers" to a file which I would generate by listing all the members of all 3 lists. Under mailman I need to add everyone from the "other 2 lists" to the first list's accept_these_nonmembers option. I didn't see an easy way to do this, so I wrote add_nonmembers. The second program I wrote I call "subscribe_lists". It's similar to add_members, except it takes an address and as many lists as you want and subscribes the address to all of the lists. When we setup a new user, we usually subscribe them to multiple lists -- I felt it was easier to have a straightforward way to do this (rather than running add_members times for lists with the address coming from stdin each time. I'll include them (since they are short) -- or is there a better way to submit these? (if anyone is even interested :-) ...dave alden ps These are based on 2.1b2. ---------------------- multipart/mixed attachment #! /usr/bin/python # # Copyright (C) 1998,1999,2000,2001,2002 by the Free Software Foundation, Inc. # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License # as published by the Free Software Foundation; either version 2 # of the License, or (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. # # argv[1] should be the name of the list. # Make sure that the list of email addresses doesn't contain any comments, # like majordomo may throw in. For now, you just have to remove them manually. """Add nonmembers to a list from the command line. Usage: add_nonmembers [options] listname Options: --accepted-file=file -a file A file containing addresses of the members to be added, one address per line, to the list of postings which are automatically accepted. If file is `-', read addresses from stdin. --moderated-file=file -m file A file containing addresses of the members to be added, one address per line, to the list of postings which are held for moderation. If file is `-', read addresses from stdin. --rejected-file=file -r file A file containing addresses of the members to be added, one address per line, to the list of postings which are automatically rejected. If file is `-', read addresses from stdin. --discarded-file=file -d file A file containing addresses of the members to be added, one address per line, to the list of postings which are automatically discarded. If file is `-', read addresses from stdin. --empty -e Empty all current addresses from the list before adding new addresses. --verbose -v Verbose output. Display messages stating whether each address was added or already in a list --help -h Print this help message and exit. listname The name of the Mailman list you are adding members to. It must already exist. You must supply at least one of -n and -d options. At most one of the files can be `-'. """ import sys import os import getopt from cStringIO import StringIO import paths # Import this /after/ paths so that the sys.path is properly hacked from email.Utils import parseaddr from Mailman import MailList from Mailman import Utils from Mailman import Message from Mailman import Errors from Mailman import mm_cfg from Mailman import i18n _ = i18n._ def usage(status, msg=''): print >> sys.stderr, _(__doc__) if msg: print >> sys.stderr, msg sys.exit(status) def readfile(filename): if filename == '-': fp = sys.stdin closep = 0 else: fp = open(filename) closep = 1 # strip all the lines of whitespace and discard blank lines lines = filter(None, [line.strip() for line in fp.readlines()]) if closep: fp.close() return lines class Tee: def __init__(self, outfp): self.__outfp = outfp def write(self, msg): sys.stdout.write(msg) self.__outfp.write(msg) class UserDesc: pass def addall(mlist, submlist, list, members, verbose, outfp): tee = Tee(outfp) for member in members: if member in mlist.accept_these_nonmembers: if verbose: print >> tee, _('%(list)s: already in accept_these_nonmembers: %(member)s') elif member in mlist.hold_these_nonmembers: if verbose: print >> tee, _('%(list)s: already in hold_these_nonmembers: %(member)s') elif member in mlist.reject_these_nonmembers: if verbose: print >> tee, _('%(list)s: already in reject_these_nonmembers: %(member)s') elif member in mlist.discard_these_nonmembers: if verbose: print >> tee, _('%(list)s: already in discard_these_nonmembers: %(member)s') else: submlist.append(member) if verbose: print >> tee, _('%(list)s: added: %(member)s') return submlist def main(): try: opts, args = getopt.getopt(sys.argv[1:], 'a:m:r:d:ehv', ['accepted-file=', 'moderated-file=', 'rejected-file=', 'discarded-file=', 'empty-list', 'verbose', 'help']) except getopt.error, msg: usage(1, msg) if len(args) <> 1: usage(1) listname = args[0].lower().strip() afile = None mfile = None rfile = None dfile = None verbose = 0 empty = 0 stdin = 0 for opt, arg in opts: if opt in ('-h', '--help'): usage(0) elif opt in ('-a', '--accepted-file'): afile = arg if afile == "-": stdin += 1 elif opt in ('-m', '--moderated-file'): mfile = arg if mfile == "-": stdin += 1 elif opt in ('-r', '--rejected-file'): rfile = arg if rfile == "-": stdin += 1 elif opt in ('-d', '--discarded-file'): dfile = arg if dfile == "-": stdin += 1 elif opt in ('-e', '--empty-list'): empty = 1 elif opt in ('-v', '--verbose'): verbose = 1 if afile is None and mfile is None and rfile is None and dfile is None: usage(1) if stdin > 1: usage(1, _('Cannot read more than one list of members ' 'from standard input.')) try: mlist = MailList.MailList(listname) except Errors.MMUnknownListError: usage(1, _('No such list: %(listname)s')) otrans = i18n.get_translation() # Read the member files try: amembers = [] mmembers = [] rmembers = [] dmembers = [] if afile: amembers = readfile(afile) if empty: mlist.accept_these_nonmembers = [] if mfile: mmembers = readfile(mfile) if empty: mlist.hold_these_nonmembers = [] if rfile: rmembers = readfile(rfile) if empty: mlist.reject_these_nonmembers = [] if dfile: dmembers = readfile(dfile) if empty: mlist.discard_these_nonmembers = [] if not amembers and not mmembers and not rmembers and not dmembers \ and not empty: usage(0, _('Nothing to do.')) s = StringIO() i18n.set_language(mlist.preferred_language) if afile: mlist.accept_these_nonmembers = addall(mlist, mlist.accept_these_nonmembers, 'accept_these_nonmembers', amembers, verbose, s) if mfile: mlist.hold_these_nonmembers = addall(mlist, mlist.hold_these_nonmembers, 'hold_these_nonmembers', mmembers, verbose, s) if rfile: mlist.reject_these_nonmembers = addall(mlist, mlist.reject_these_nonmembers, 'reject_these_nonmembers', rmembers, verbose, s) if dfile: mlist.discard_these_nonmembers = addall(mlist, mlist.discard_these_nonmembers, 'discard_these_nonmembers', dmembers, verbose, s) mlist.Save() finally: mlist.Unlock() i18n.set_translation(otrans) if __name__ == '__main__': main() ---------------------- multipart/mixed attachment #! /usr/bin/python # # Copyright (C) 1998,1999,2000,2001,2002 by the Free Software Foundation, Inc. # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License # as published by the Free Software Foundation; either version 2 # of the License, or (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. # # argv[1] should be the name of the list. # argv[2] should be the list of non-digested users. # argv[3] should be the list of digested users. # Make sure that the list of email addresses doesn't contain any comments, # like majordomo may throw in. For now, you just have to remove them manually. """Add members to a list from the command line. Usage: subscribe_list [options] listname [listname ...] Options: --regular-member=addr1 -r addr1 Add addr1 as a regular (non-digest) member. --digest-member=addr1 -d addr1 Add add1 as a digest member. --welcome-msg= -w Set whether or not to send the list members a welcome message, overriding whatever the list's `send_welcome_msg' setting is. --admin-notify= -a Set whether or not to send the list administrators a notification on the success/failure of these subscriptions, overriding whatever the list's `admin_notify_mchanges' setting is. --help -h Print this help message and exit. listname The name of the Mailman list you are adding members to. It must already exist. You must supply at least one of -n and -d options. At most one of the files can be `-'. """ import sys import os import getopt from cStringIO import StringIO import paths # Import this /after/ paths so that the sys.path is properly hacked from email.Utils import parseaddr from Mailman import MailList from Mailman import Utils from Mailman import Message from Mailman import Errors from Mailman import mm_cfg from Mailman import i18n _ = i18n._ def usage(status, msg=''): print >> sys.stderr, _(__doc__) if msg: print >> sys.stderr, msg sys.exit(status) class Tee: def __init__(self, outfp): self.__outfp = outfp def write(self, msg): sys.stdout.write(msg) self.__outfp.write(msg) class UserDesc: pass def add(mlist, member, digest, ack, outfp): tee = Tee(outfp) mlist_name = mlist.internal_name() userdesc = UserDesc() userdesc.fullname, userdesc.address = parseaddr(member) userdesc.digest = digest try: mlist.ApprovedAddMember(userdesc, ack, 0) except Errors.MMAlreadyAMember: print >> tee, _('Already a member of %(mlist_name)s: %(member)s') except Errors.MMBadEmailError: if userdesc.address == '': print >> tee, _('Bad/Invalid email address: blank line') else: print >> tee, _('Bad/Invalid email address: %(member)s') except MMHostileAddress: print >> tee, _('Hostile address (illegal characters): %(member)s') else: print >> tee, _('Subscribed: %(member)s to %(mlist_name)s') def main(): try: opts, args = getopt.getopt(sys.argv[1:], 'a:r:d:w:h', ['admin-notify=', 'regular-member=', 'digest-member=', 'welcome-msg=', 'help']) except getopt.error, msg: usage(1, msg) if len(args) < 1: usage(1, args) listnames = args send_welcome_msg = None admin_notif = None member_address = None digest_member = 0 for opt, arg in opts: if opt in ('-h', '--help'): usage(0) elif opt in ('-d', '--digest-member'): member_address = arg digest_member = 1 elif opt in ('-r', '--regular-member'): member_address = arg digest_member = 0 elif opt in ('-w', '--welcome-msg'): if arg.lower()[0] == 'y': send_welcome_msg = 1 elif arg.lower()[0] == 'n': send_welcome_msg = 0 else: usage(1, _('Bad argument to -w/--welcome-msg: %(arg)s')) elif opt in ('-a', '--admin-notify'): if arg.lower()[0] == 'y': admin_notif = 1 elif arg.lower()[0] == 'n': admin_notif = 0 else: usage(1, _('Bad argument to -a/--admin-notify: %(arg)s')) if member_address is None: usage(1) listnames = [n.lower().strip() for n in listnames] if not listnames: print _('Nothing to do.') sys.exit(0) for listname in listnames: try: mlist = MailList.MailList(listname) except Errors.MMUnknownListError: usage(1, _('No such list: %(listname)s')) # Set up defaults if send_welcome_msg is None: send_welcome_msg = mlist.send_welcome_msg if admin_notif is None: admin_notif = mlist.admin_notify_mchanges otrans = i18n.get_translation() # Read the regular and digest member files try: s = StringIO() i18n.set_language(mlist.preferred_language) add(mlist, member_address, digest_member, send_welcome_msg, s) if admin_notif: realname = mlist.real_name subject = _('%(realname)s subscription notification') msg = Message.UserNotification( mlist.owner, Utils.get_site_email(), subject, s.getvalue(), mlist.preferred_language) msg.send(mlist) mlist.Save() finally: mlist.Unlock() i18n.set_translation(otrans) if __name__ == '__main__': main() ---------------------- multipart/mixed attachment-- From Matt_Domsch@Dell.com Thu Jul 11 22:10:31 2002 From: Matt_Domsch@Dell.com (Matt_Domsch@Dell.com) Date: Thu, 11 Jul 2002 16:10:31 -0500 Subject: [Mailman-Developers] .lower() for older pythons Message-ID: > I' released Mailman 2.0.12 which fixes a cross-site scripting > vulnerability, among other changes. I recommend that folks upgrade > their 2.0.x systems to this new version. See below for a NEWS file > excerpt. Thanks for this update. I've run across one problem. In Mailman/MailCommandHandler.py, ParseMailCommands function: + precedence = msg.get('precedence', '').lower() + ack = msg.get('x-ack', '').lower() With my python (1.5.2-30 as in Red Hat Linux 7.1), this generates lots of errors in mailman/logs/error: Jul 11 15:30:00 2002 qrunner(17873): Traceback (innermost last): Jul 11 15:30:00 2002 qrunner(17873): File "/home/mailman/cron/qrunner", line 283, in ? Jul 11 15:30:00 2002 qrunner(17873): kids = main(lock) Jul 11 15:30:00 2002 qrunner(17873): File "/home/mailman/cron/qrunner", line 253, in main Jul 11 15:30:00 2002 qrunner(17873): keepqueued = dispose_message(mlist, msg, msgdata) Jul 11 15:30:00 2002 qrunner(17873): File "/home/mailman/cron/qrunner", line 157, in dispose_message Jul 11 15:30:00 2002 qrunner(17873): mlist.ParseMailCommands(msg) Jul 11 15:30:00 2002 qrunner(17873): File "/home/mailman/Mailman/MailCommandHandler.py", line 123, in ParseMailCommands Jul 11 15:30:00 2002 qrunner(17873): precedence = msg.get('precedence', '').lower() Jul 11 15:30:00 2002 qrunner(17873): AttributeError : 'string' object has no attribute 'lower' I believe the proper fix is: + precedence = string.lower(msg.get('precedence', '')) + ack = string.lower(msg.get('x-ack', '')) instead. With this, it works and doesn't generate those errors. I'm not on mailman-developers, so please cc me on any replies. Thanks, Matt -- Matt Domsch Sr. Software Engineer, Lead Engineer, Architect Dell Linux Solutions www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com #1 US Linux Server provider for 2001 and Q1/2002! (IDC May 2002) From barry@zope.com Thu Jul 11 22:18:41 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 11 Jul 2002 17:18:41 -0400 Subject: [Mailman-Developers] .lower() for older pythons References: Message-ID: <15661.63025.671857.8305@anthem.wooz.org> >>>>> "MD" == Matt Domsch writes: MD> Thanks for this update. I've run across one problem. In MD> Mailman/MailCommandHandler.py, ParseMailCommands function: | + precedence = msg.get('precedence', '').lower() | + ack = msg.get('x-ack', '').lower() MD> With my python (1.5.2-30 as in Red Hat Linux 7.1), this MD> generates lots of errors in mailman/logs/error: Damn! It's really getting hard to keep Python 1.5.2 in mind. :( MD> I believe the proper fix is: MD> + precedence = string.lower(msg.get('precedence', '')) + ack = MD> string.lower(msg.get('x-ack', '')) MD> instead. With this, it works and doesn't generate those MD> errors. I'm not on mailman-developers, so please cc me on any MD> replies. You're exactly right. Attached is a patch. I guess I have to generate a 2.0.13. :( -Barry From barry@zope.com Thu Jul 11 22:20:13 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 11 Jul 2002 17:20:13 -0400 Subject: [Mailman-Developers] .lower() for older pythons References: Message-ID: <15661.63117.176552.212148@anthem.wooz.org> >>>>> "MD" == Matt Domsch writes: MD> Thanks for this update. I've run across one problem. In MD> Mailman/MailCommandHandler.py, ParseMailCommands function: | + precedence = msg.get('precedence', '').lower() | + ack = msg.get('x-ack', '').lower() MD> With my python (1.5.2-30 as in Red Hat Linux 7.1), this MD> generates lots of errors in mailman/logs/error: Damn! It's really getting hard to keep Python 1.5.2 in mind. :( MD> I believe the proper fix is: MD> + precedence = string.lower(msg.get('precedence', '')) + ack = MD> string.lower(msg.get('x-ack', '')) MD> instead. With this, it works and doesn't generate those MD> errors. I'm not on mailman-developers, so please cc me on any MD> replies. You're exactly right. Attached is a patch. I guess I have to generate a 2.0.13. :( -Barry -------------------- snip snip -------------------- Index: MailCommandHandler.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Attic/MailCommandHandler.py,v retrieving revision 1.70.2.1 diff -u -r1.70.2.1 MailCommandHandler.py --- MailCommandHandler.py 2 Jul 2002 16:33:23 -0000 1.70.2.1 +++ MailCommandHandler.py 11 Jul 2002 21:16:47 -0000 @@ -120,8 +120,8 @@ # of these clues, so there's little we can do to break loops in that # case, except throttle the number of responses sent to any one # requester in a day. That's a job for MM2.1. - precedence = msg.get('precedence', '').lower() - ack = msg.get('x-ack', '').lower() + precedence = string.lower(msg.get('precedence', '')) + ack = string.lower(msg.get('x-ack', '')) beenthere = msg.get('x-beenthere', '') listid = msg.get('list-id', '') if (precedence in ('bulk', 'list', 'junk') or From noreply@sourceforge.net Thu Jul 11 23:28:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jul 2002 15:28:56 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-577685 ] sh syntax problem in configure Message-ID: Bugs item #577685, was opened at 2002-07-05 03:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=577685&group_id=103 Category: configuring/installing Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: sh syntax problem in configure Initial Comment: in 2.0.12 configure script includes a statement: if [ "$?" == "1" ] which should be in a traditional sh: if [ "$?" = "1" ] (Note single =, not double =) configure fails on solaris 8 with double =, while the error was ignored on FreeBSD. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-11 18:28 Message: Logged In: YES user_id=12800 Can you please try the attached patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=577685&group_id=103 From noreply@sourceforge.net Thu Jul 11 23:29:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jul 2002 15:29:42 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-577685 ] sh syntax problem in configure Message-ID: Bugs item #577685, was opened at 2002-07-05 03:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=577685&group_id=103 Category: configuring/installing Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: sh syntax problem in configure Initial Comment: in 2.0.12 configure script includes a statement: if [ "$?" == "1" ] which should be in a traditional sh: if [ "$?" = "1" ] (Note single =, not double =) configure fails on solaris 8 with double =, while the error was ignored on FreeBSD. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-11 18:29 Message: Logged In: YES user_id=12800 Let's try that again with the checkbox checked off. :/ ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-11 18:28 Message: Logged In: YES user_id=12800 Can you please try the attached patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=577685&group_id=103 From noreply@sourceforge.net Thu Jul 11 23:30:35 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 11 Jul 2002 15:30:35 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-577685 ] sh syntax problem in configure Message-ID: Bugs item #577685, was opened at 2002-07-05 03:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=577685&group_id=103 Category: configuring/installing Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: sh syntax problem in configure Initial Comment: in 2.0.12 configure script includes a statement: if [ "$?" == "1" ] which should be in a traditional sh: if [ "$?" = "1" ] (Note single =, not double =) configure fails on solaris 8 with double =, while the error was ignored on FreeBSD. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-11 18:30 Message: Logged In: YES user_id=12800 Note that that patch is against configure.in, so you'll need to run autoreconf (or just patch configure by hand). Let me know if that's a problem. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-11 18:29 Message: Logged In: YES user_id=12800 Let's try that again with the checkbox checked off. :/ ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-11 18:28 Message: Logged In: YES user_id=12800 Can you please try the attached patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=577685&group_id=103 From barry@zope.com Fri Jul 12 00:09:40 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 11 Jul 2002 19:09:40 -0400 Subject: [Mailman-Developers] suggestion for configure References: <5.1.0.14.2.20020329012652.0553d080@lennier.cc.vt.edu> Message-ID: <15662.4148.663047.919769@anthem.wooz.org> A long time ago, Ron Jarrell wrote: RJ> Add a --with-fqdn and --with-url or equivalent. Done, except I'm calling them --with-mailhost and --with-urlhost. ;) I'm also simplifying the configure tests for the defaults of these two values. Now, it'll just use the results of socket.getfqdn() without all the fancy (and fragile) attempts at whacking off the leading `www'. So by default, when I run it I get DEFAULT_EMAIL_HOST and DEFAULT_URL_HOST set to "yyz.zope.com". Setting DEFAULT_URL_HOST to that isn't correct for my machine, so I now run configure --with-urlhost=localhost Of course, it's also easy to just change these values in mm_cfg.py -Barry From barry@zope.com Fri Jul 12 00:29:00 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 11 Jul 2002 19:29:00 -0400 Subject: [Mailman-Developers] MM2.1 CVS: broken configure script References: <15597.19117.177260.314225@gargle.gargle.HOWL> Message-ID: <15662.5308.882845.568867@anthem.wooz.org> A while ago Matthias Klose wrote: MK> mailman checks for the installation directories during MK> configury. IMO this wrongly assumes, that | - the build machine is the target machine | - the directories already exist during configuration | - you don't use a temporary installation directory MK> 2.1b2 works ok. Found this while making experimental Debian MK> packages. I'm adding a configure switch --with(out)-permcheck. By default, the permissions on the --prefix directory are checked, unless you add --without-permicheck, then that check is skipped. Hope that solves the problem. -Barry From jwblist@olympus.net Fri Jul 12 07:09:42 2002 From: jwblist@olympus.net (John W Baxter) Date: Thu, 11 Jul 2002 23:09:42 -0700 Subject: [Mailman-Developers] OSX installation problem - no "mailman" user In-Reply-To: References: Message-ID: Greg Westin wrote: >I sent this question to the mailman-users list and got no response, so I >thought maybe I should try here. I don't know if this is a problem >because I'm a novice at these UNIX installations, or if there's >something wrong with the Darwin installer: I haven't looked at the configure script (at all...I don't know what language it's in), but the symptoms sound as if the script is not using normal system calls to retrieve the mailman user information... the Pythonic pwd.getpwnam() for example would get it just fine. Is it doing the equivalent of grep mailman /etc/passwd ?...if so it cannot succeed in a proper Mac OS X (although one could create the user, find the numeric UID, and use vipw to install the user in /etc/passwd and whatever we have to install the group in /etc/group. Barry...you probably know this, but NetInfo is going away in a month or so ("Jaguar") to be replaced by an LDAP-based solution. So doing a NetInfo-specific fix would probably be unwise. --John (not under Jaguar NDA, and without Jaguar) -- John Baxter Port Ludlow, WA, USA I am NOT out of the office. I will respond if and when I get around to it. From chuqui@plaidworks.com Fri Jul 12 07:23:45 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Thu, 11 Jul 2002 23:23:45 -0700 Subject: [Mailman-Developers] OSX installation problem - no "mailman"user In-Reply-To: Message-ID: On 7/11/02 11:09 PM, "John W Baxter" wrote: > Barry...you probably know this, but NetInfo is going away in a month or so > ("Jaguar") to be replaced by an LDAP-based solution. So doing a > NetInfo-specific fix would probably be unwise. As I understand things, this is not true. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ IMHO: Jargon. Acronym for In My Humble Opinion. Used to flag as an opinion something that is clearly from context an opinion to everyone except the mentally dense. Opinions flagged by IMHO are actually rarely humble. IMHO. (source: third unabridged dictionary of chuqui-isms). From jwblist@olympus.net Fri Jul 12 22:13:33 2002 From: jwblist@olympus.net (John W Baxter) Date: Fri, 12 Jul 2002 14:13:33 -0700 Subject: [Mailman-Developers] OSX installation problem - no "mailman" user In-Reply-To: <20020712113743.GC3678@lummux.tchpc.tcd.ie> References: <20020712113743.GC3678@lummux.tchpc.tcd.ie> Message-ID: At 12:37 +0100 7/12/2002, Robert Crosbie wrote: >John W Baxter hath declared on Thursday the 11 day of July 2002 :-: >> Greg Westin wrote: >> >> >I sent this question to the mailman-users list and got no response, so I >> >thought maybe I should try here. I don't know if this is a problem >> >because I'm a novice at these UNIX installations, or if there's >> >something wrong with the Darwin installer: >> >> I haven't looked at the configure script (at all...I don't know what >> language it's in), > >Basically a shell script... > >> but the symptoms sound as if the script is not using >> normal system calls to retrieve the mailman user information... the >> Pythonic pwd.getpwnam() for example would get it just fine. Is it doing > >Perhaps you should have checked the script, it does in fact use >pwd.getpwuid() and/or pwd.getpwnam(). >I assume these work properly on OSX. Well, pwd.getpwnam() doesn't work "properly" but the failure is not involved here. (The encrypted password is returned by getpwnam regardless of whether root or someone else runs it. Coupled with the traditional 8-character crypt() used for the passwords, this is a major flaw in Apple's security. This isn't a Python thing...the Perl equivalent also gets the password field.) I haven't put Mailman on my Mac OS X machine. [I haven't bothered to replace sendmail, either, but before actually allowing port 25 connections I need a mail program I can configure...fortunately while I've been driving Unix since 1995 "at" work (same chair), we ditched sendmail when Exim became viable. So I know almost as little about sendmail as Aunt Sally does.] --john -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From noreply@sourceforge.net Sat Jul 13 02:16:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jul 2002 18:16:22 -0700 Subject: [Mailman-Developers] [ mailman-Patches-567834 ] Fix for options wording Message-ID: Patches item #567834, was opened at 2002-06-12 00:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=567834&group_id=103 Category: Web UI Group: Mailman 2.1 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jon Parise (parise) Assigned to: Nobody/Anonymous (nobody) Summary: Fix for options wording Initial Comment: On the subscriber's options screen in Mailman 2.1b2+, this text existis: "Conceal yourself from subscriber list? When someone views the list membership, your email address is normally shown (in an obscured fashion to thwart spam harvesters). If you do not want your email address to show up on this membership roster, select No for this option." It sounds like that "No" should be changed to a "Yes" for the statements to agree and make sense. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-12 21:16 Message: Logged In: YES user_id=12800 Right right, and I will change this (with a slight rewording). Note to translation teams: you'll need to update your options.html files too! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=567834&group_id=103 From barry@zope.com Sat Jul 13 03:01:11 2002 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 12 Jul 2002 22:01:11 -0400 Subject: [Mailman-Developers] phantom moderation... References: <5.1.0.14.2.20020707085658.00a47510@mail.vt.edu> <20020707154028.GF25902@rezo.net> <20020707160006.GA28855@rezo.net> Message-ID: <15663.35303.438377.612992@anthem.wooz.org> Thank you thank you thank you Fil! -Barry -------------------- snip snip -------------------- Index: checkdbs =================================================================== RCS file: /cvsroot/mailman/mailman/cron/checkdbs,v retrieving revision 2.12 diff -u -r2.12 checkdbs --- checkdbs 28 May 2002 03:11:19 -0000 2.12 +++ checkdbs 13 Jul 2002 02:00:12 -0000 @@ -54,7 +54,7 @@ midnightToday = Utils.midnight() evictions = [] for sender in mlist.hold_and_cmd_autoresponses.keys(): - date, count = mlist.hold_and_cmd_autoresponses[sender] + date, respcount = mlist.hold_and_cmd_autoresponses[sender] if Utils.midnight(date) < midnightToday: evictions.append(sender) if evictions: From noreply@sourceforge.net Sat Jul 13 03:03:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 12 Jul 2002 19:03:02 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-566482 ] Mod req notification but nothing shown Message-ID: Bugs item #566482, was opened at 2002-06-09 10:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=566482&group_id=103 Category: None Group: 2.1 beta >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Alan Schwartz (alansz) Assigned to: Nobody/Anonymous (nobody) Summary: Mod req notification but nothing shown Initial Comment: Running 2.1b2 cvs checkout of June 3 2002. Upgraded a previously 2.0.11 server with several lists. Everything seems to be operating ok mailwise except I'm receiving a daily email from checkdbs on two of the lists directing me to their admindb pages for pending requests. When I visit those urls, there are no pending requests. The lists' request.db's appear to be binary-identical to those of the other mailing lists that don't have any pending requests (that is, empty). I haven't managed to figure out why checkdbs is generating these notices. Help would be appreciated. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-12 22:03 Message: Logged In: YES user_id=12800 Fil correctly diagnosed the problem and provided a fix., see attached. Also now in CVS. ---------------------------------------------------------------------- Comment By: Alan Schwartz (alansz) Date: 2002-06-11 11:38 Message: Logged In: YES user_id=559669 However, I got a new one yesterday for a list that doesn't allow subscription requests at all. It has 13 members. I had emailed a message to the list the day before, and there were a 3 bounces (setting bounce score to 1.0 for each). But no subscribe requests or unsubscribe requests. Maybe it's all tied into the bounce/confirm processing, though? ---------------------------------------------------------------------- Comment By: Michael Totschnig (totschnig) Date: 2002-06-11 09:28 Message: Logged In: YES user_id=318184 I see these phantom request notifcations too, and I have spotted a pattern that might help debug them. I did not see them every morning, but only once in a while. It seems that they are triggered by subscriptions to the lists. Every time someone has confirmed his subscription during the preceding 24 hours, I get these notification requests and the number of requests mentioned in the notification is identical to the number of subscription confirmations. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=566482&group_id=103 From noreply@sourceforge.net Sat Jul 13 21:22:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jul 2002 13:22:39 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-540980 ] replyaddress on subscr.: fqdn not domain Message-ID: Bugs item #540980, was opened at 2002-04-08 13:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=540980&group_id=103 Category: mail delivery Group: 2.1 beta >Status: Deleted Resolution: None >Priority: 1 Submitted By: Markus Mandalka (mandalka) Assigned to: Nobody/Anonymous (nobody) Summary: replyaddress on subscr.: fqdn not domain Initial Comment: My fqdn of the server is kommunikationssystem.de but mailman should run as lists.kommunikationssystem.de. If i run configure with hostname lists.kommunikationssystem.de it seems not to be configured right. So i changed in defaults.py and / or mm_cfg.py the values. Most is ok, but on subscribing the reply-Adress (in the header) of the mail asking for confirmation is listname@kommunikationssystem.de and not listname@lists.kommunikationssystem.de ... Does mailman take the hostname of the server in some parts and not the values of emailhost and urlhost in the config ? ---------------------------------------------------------------------- >Comment By: Markus Mandalka (mandalka) Date: 2002-07-13 20:22 Message: Logged In: YES user_id=509217 it was the mta (sendmail) that rewrote adresses without having set this up (it was a tool, that made the sendmail.cf). With exim no problem. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-04-11 22:02 Message: Logged In: YES user_id=12800 In that case, it's very likely that it's your MTA that's rewriting these addresses. Which one are you using? You can test this by turning off qrunner (i.e. bin/mailmanctl stop), and running the queues one-by-one until you see the message show up in the qfiles/out directory. See bin/qrunner for how to do this. Once the message is in qfiles/out, do a bin/dumpdb on the .pck file. If it's got the right headers, it's not Mailman's fault! :) ---------------------------------------------------------------------- Comment By: Markus Mandalka (mandalka) Date: 2002-04-10 09:59 Message: Logged In: YES user_id=509217 The hostname is right in options of the list, but the first mail (i have to confirm) comes not from that address but from the fqdn! ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-04-09 19:53 Message: Logged In: YES user_id=12800 Did you create the list before or after you edited mm_cfg.py? Note that any changes to DEFAULT_EMAIL_HOST that you make in mm_cfg.py does not affect already created lists. You need to go to the General catagory and change the host_name attribute. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=540980&group_id=103 From noreply@sourceforge.net Sat Jul 13 21:35:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 13 Jul 2002 13:35:41 -0700 Subject: [Mailman-Developers] [ mailman-Feature Requests-581103 ] do not moderate mails from nntp-groups Message-ID: Feature Requests item #581103, was opened at 2002-07-13 20:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=581103&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Markus Mandalka (mandalka) Assigned to: Nobody/Anonymous (nobody) Summary: do not moderate mails from nntp-groups Initial Comment: i wish to have an setting for the nntp-gateway that allows posting the nntp-articles without moderating on lists, that need confirmation for member-postings. The moderation should only be for the emails sendet to the list, not for nntp-postings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=581103&group_id=103 From At10109fer@aol.com Sun Jul 14 05:32:15 2002 From: At10109fer@aol.com (At10109fer@aol.com) Date: Sun, 14 Jul 2002 00:32:15 EDT Subject: [Mailman-Developers] HELP Message-ID: I will appreciate your help.-I am traying to download & install the Mailman to Windows could you have info abuot that?.Thank you very much in advance.SINCERELY YOURS FERNANDO ESPINOSA R. From dan@dankohn.com Sun Jul 14 10:42:54 2002 From: dan@dankohn.com (Dan Kohn) Date: Sun, 14 Jul 2002 02:42:54 -0700 Subject: [Mailman-Developers] Scrubbing Mailman lists Message-ID: I'd appreciate help adding the following features to Mailman to "scrub" questionable mailing lists into fully verified opt-in lists: I want to start with an unverified mailing list, and segment it into 2 lists containing those who have verified acceptance and those who haven't. Specifically, I'd like to add a footer to messages being sent to the non-verified list segment asking them to click a URL or send email to an address to verify. Taking the verification step would then move them onto the verified list segment. Also, anyone posting to the list would be moved to the verified list segment. I'd like this whole bundle of features to be bottled up as a standard Mailman option for "scrubbing" lists that are not initially 100% verified opt-in (i.e., that didn't originate with Mailman's confirm subscription feature turned on). Has anyone put something similar together already? If not, and you would be interested in doing so, could you please email me directly about doing so as consulting work? Since Mailman is GPL, I would of course release all patches back to the community. Thanks in advance for your help. - dan -- Dan Kohn From dmick@utopia.West.Sun.COM Sun Jul 14 23:49:25 2002 From: dmick@utopia.West.Sun.COM (Dan Mick) Date: Sun, 14 Jul 2002 15:49:25 -0700 Subject: [Mailman-Developers] HELP References: Message-ID: <3D31FFF5.59B2B8D@utopia.west.sun.com> At10109fer@aol.com wrote: > > I will appreciate your help.-I am traying to download & install the Mailman > to Windows could you have info abuot that?.Thank you very much in > advance.SINCERELY YOURS FERNANDO ESPINOSA R. http://www.python.org/cgi-bin/faqw-mm.py?req=all#1.6 From dave@umiacs.umd.edu Mon Jul 15 14:00:56 2002 From: dave@umiacs.umd.edu (Dave Stern - Former Rocket Scientist) Date: Mon, 15 Jul 2002 09:00:56 -0400 (EDT) Subject: [Mailman-Developers] mailman and nfs Message-ID: I set up mailman (2.0.11) on a solaris 2.8 machine and am relatively happy with it. For various reasons, we want the mailman software (and homedir) nfsmounted from elsewhere. Configuring it with a hard nfsmount seems to work well but some here would rather it be automounted. Does mailman support automount? Is it suggested? I got it working with automount but on occasion get unexpected results eg webpage unavailable and giving traceback. I'm wondering if this is just a result of my testing (manually unmounting, reconfiguring, remounting) and getting a sort of race condition ie the partition isn't yet available for web access. Anyone? Thanks =-=-=-=-=-=-=-=-=-=-=-=- generated by /dev/dave -=-=-=-=-=-=-=-=-=-=-=-=-=-= David Stern University of Maryland Institute for Advanced Computer Studies From jra@baylink.com Mon Jul 15 18:06:44 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 15 Jul 2002 13:06:44 -0400 Subject: [Mailman-Developers] Scrubbing Mailman lists In-Reply-To: ; from Dan Kohn on Sun, Jul 14, 2002 at 02:42:54AM -0700 References: Message-ID: <20020715130644.14378@scfn.thpl.lib.fl.us> On Sun, Jul 14, 2002 at 02:42:54AM -0700, Dan Kohn wrote: > I'd appreciate help adding the following features to Mailman to "scrub" > questionable mailing lists into fully verified opt-in lists: > > I want to start with an unverified mailing list, and segment it into 2 > lists containing those who have verified acceptance and those who > haven't. Specifically, I'd like to add a footer to messages being sent > to the non-verified list segment asking them to click a URL or send > email to an address to verify. Taking the verification step would then > move them onto the verified list segment. Also, anyone posting to the > list would be moved to the verified list segment. I'd like this whole > bundle of features to be bottled up as a standard Mailman option for > "scrubbing" lists that are not initially 100% verified opt-in (i.e., > that didn't originate with Mailman's confirm subscription feature turned > on). That sounds an awful lot like the "invitation" feature in 2.1. If you haven't already looked at that, take a gander, and see what you think. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From noreply@sourceforge.net Tue Jul 16 15:44:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jul 2002 07:44:15 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-582274 ] Duplicate Subscription Request Message-ID: Bugs item #582274, was opened at 2002-07-16 10:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=582274&group_id=103 Category: (un)subscribing Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: rich cowan (leftlink) Assigned to: Nobody/Anonymous (nobody) Summary: Duplicate Subscription Request Initial Comment: Someone submitted a subscription request twice and instead of rejecting the second request, Mailman allowed it and it appeared twice in the subscriber approve window. here is an example of how this appeared: Date: Tue, 16 Jul 2002 06:25:19 -0400 Subject: 2 devel admin request(s) waiting From: devel-admin@lists.democracygroups.org To: devel-admin@lists.democracygroups.org X-Ack: no X-BeenThere: devel@lists.democracygroups.org X-Mailman-Version: 2.0.9 Precedence: bulk Message-Id: Sender: devel-owner@lists.democracygroups.org Errors-To: devel-owner@lists.democracygroups.org X-BeenThere: devel@lists.democracygroups.org List-Help: List-Post: List-Subscribe: , List-Id: OC Software Development Volunteer List-Unsubscribe: , List-Archive: Status: The devel@lists.democracygroups.org mailing list has 2 request(s) waiting for your consideration at: http://lists.democracygroups.org/mailman/a dmindb/devel Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending subscriptions: ksnyder@..ny.org Tue Jul 16 05:10:03 2002 ksnyder@..ny.org Tue Jul 16 05:20:02 2002 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=582274&group_id=103 From chuqui@plaidworks.com Tue Jul 16 18:58:00 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 16 Jul 2002 10:58:00 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... Message-ID: Howdy, ya'll. Back from vacation, and opening up a few can o' worms (gotta big can opener here!) for everyone to chew on.... Apologize if this goes all over the map, a bunch of things have been simmering and I want to pass them along to get your perspective, see if they are issues that ought to be considered in Mailman somehow, and perhaps warn you of stuff I'm seeing before it hits you... First, a minor announcement. I'm no longer in charge of the mailing lists at apple, sort of. We've hired a person full-time, and he's been taking over the lists server as his full-time responsibility, allowing me to go off and work on other projects. I'm still in the loop, just not "it". I'm still going to be heavily involved as we move that box to Mailman 2.1, and after that, probably fade a bit more into the woodwork (I still run my Mailman box at home, however, so I'm not going away. JC, quite jeering) Anyway, on to issues more substantive. With the explosion of spam, privacy issues and protection issues have been of great interest around here, including fascinating (but not family friendly) discussions with our legal beagles. The end result of all of that is a decision that subscriber e-mail addresses are considered a significant asset that needs to be protected to the greatest extent possible. We're currently evaluating exactly what that means (and it means the list rules/T&Cs are going to need to be revamped as well, in ways we're still figuring out) to do what we can to make sure people who post to the mailing lists don't get harvested. One thing we're definitely doing is moving to a cloaked archive. Since we already distribute all archives out of HTTP, not FTP, we're working on a CGI that'll strip all e-mail information out of messages on the fly (among other things, like header cleanup and some trivial formatting fixes). The idea is simple -- we've finally hit the point where you can't put an e-mail address up on a public site under any cirucmstance safely, so we're having to move to a system where we simply don't do that. I think the Mailman stuff needs to think about this, also. It impacts the archiving setup and other issues, but the harvesters have hit the point where we simply can't risk disclosing that info. It creates other problems -- you can't see a posting in the archive and send email to that person with more questions (or answers), but that seems trivial compared to the problems the spammers are causing. A secondary issue here is the problem of disclosing admins and admin addresses. I know we've hashed that through once, but we've come to the (somewhat reluctant) decision to whitelist all public, non-personal email addresses. We're going to be implementing TMDA to do this, and will be switching all admin to generic addresses that filter through TMDA, as well as things like postmaster@ and the like. While I hate making users jump through hoops to get through to a real person (for those that don't know, TMDA is an overt whitelist. If you're not on the whitelist, you get mail back telling you to take some action, and until you do, the mail isn't delivered), but the abuse by the spammers on admin addresses is now so bad I'm declaring defeat and going to the whitelist. I'm going to look and see if I can interface TMDA to the subscriber databases so that subscribers are by definition whitelisted, but we've hit the poiint where we have to do this. I'm not happy about it, but the war is lost, I think. And speaking of privacy, harvesting and spamming, a new and disturbing thing happened this weekend that I want to bring up -- one for which I have lots of questions, but no real answers. A bunch of users on some of our mail lists were spammed, and it became very clear very quickly that addresses were harvested off of at least one of our mail lists. As you might guess, a lynch mob formed, and I lit the first virtual torch and we all sharpened the pitchforks. Fortunately, the person who did it came forward to me and admitted guilt, and explained what happened. And what happened is pretty damn disturbing. See, he had one of those "I must tell the masses!" moments, where he finally felt it was time to send out a call to arms on a subject he felt strongly about. So what he did was open up his address book and send his message to everyone in it. And he's running one of these new e-mail clients that happily caches addresses it sees in case you want them again. So all of the addresses of people posting to the mailing lists he subscribed to were in his address book cache, so when he grabbed his address book, he grabbed all of those addresses, too. So we have a clear violation of our anti-harvesting rules -- yet he didn't overtly harvest. He just grabbed what was in his address book at the time. This creates a major privacy quagmire. How do you set up rules for something like that? Where does ownership and protection end? (I'm talking ethically, not technically. I think we all realize that once someone posts email to a list, you've given up control to anyone who doesn't feel obligated to follow the rules). This wasn't a case of overtly violating the rules, but of a piece of technology creating a situation where it wasn't understood there were rules being violated. I just don't know how to deal with the issues this address caching causes. Ultimately, we're going to have to rethink our "no harvesting" rules, and likely also write disclaimers explaining what our limits are. We've actually considered switching our lists to obscured addresses, turned that down as being worse than the disease (for now). But now we're wondering if we have to go to some sort of address cloaking ON lists, maybe some kind of address remapping through the server for replies, something. And I'm gritting my teeth at the developers who created those @#$@$#@$#23 caches (which are nice in some ways) for not also creating some way to flag addresses as not cacheable. Because, IMHO, that'd solve this problem. But they didn't. Grumble. I'm curious what people think about this latest thing. The good news is he wasn't trying to harvest us. The bad news is, he wasn't trying to harvest us. And the b-tch of it is, I really don't have a comfortable feeling for how to deal with this new situation yet... But I think it's an issue we have to come to grips with. Are we hitting a point where mail list servers have to act as blind front ends for all of the subscribers, where replies are processed by those servers, and the server then takes on the job of acting as a troll-exterminator and spam blocker? And what does that really mean for things like Mailman? Happy Macworld Expo week, all. If you need me, I'll be in the war room, beating my head against a wall. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ He doesn't have ulcers, but he's a carrier. From jwblist@olympus.net Tue Jul 16 20:19:16 2002 From: jwblist@olympus.net (John W Baxter) Date: Tue, 16 Jul 2002 12:19:16 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: References: Message-ID: At 10:58 -0700 7/16/2002, Chuq Von Rospach wrote: >Are we hitting a point where mail list servers have to act as blind front >ends for all of the subscribers, where replies are processed by those >servers, and the server then takes on the job of acting as a >troll-exterminator and spam blocker? And what does that really mean for >things like Mailman? I don't think so, quite yet. But I think we've reached the point that it is prudent for a user to use a different throwaway address for each different place one exposes one's address. (The address I use here isn't unique, but it is throwaway. And it isn't badly spammed yet.) And we've reached the point that it's probably imprudent to gate mailing lists and Usenet (which we've never done anyhow). I use an @spamcop.net address on Usenet...I get the distinct impression that most harvesters don't bother with those. I think the issue is larger than just mailing lists: SMTP-based email will be unusable soon. The replacement will be something permission based with electronic signatures involved, and some TMDA-like way to get started conversing with someone. --John the Disgusted -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From chuqui@plaidworks.com Tue Jul 16 20:58:05 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 16 Jul 2002 12:58:05 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: Message-ID: On 7/16/02 12:19 PM, "John W Baxter" wrote: > I don't think so, quite yet. But I think we've reached the point that it > is prudent for a user to use a different throwaway address for each > different place one exposes one's address. (The address I use here isn't > unique, but it is throwaway. And it isn't badly spammed yet.) Problem is, many users don't know how. And one could argue who ought to solve this problem. Should users be forced to jump through hoops to use a mail list safely? Or is it the user's decision how safe to be? I could make a pithy comparison between spammers, computer viruses, AIDS and safe sex, but you'd all throw veggies at me. > And we've reached the point that it's probably imprudent to gate mailing > lists and Usenet (which we've never done anyhow). Agreed, unless it's carefully controlled. We gateway only to internal, private lists. > I think the issue is larger than just mailing lists: SMTP-based email will > be unusable soon. No, but it has to adapt and evolve. Quickly. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after From barry@zope.com Tue Jul 16 22:37:45 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 16 Jul 2002 17:37:45 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... References: Message-ID: <15668.37417.657983.567997@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> First, a minor announcement. I'm no longer in charge of the CVR> mailing lists at apple, sort of. We've hired a person CVR> full-time, and he's been taking over the lists server as his CVR> full-time responsibility, allowing me to go off and work on CVR> other projects. I'm still in the loop, just not "it". I'm CVR> still going to be heavily involved as we move that box to CVR> Mailman 2.1, and after that, probably fade a bit more into CVR> the woodwork (I still run my Mailman box at home, however, so CVR> I'm not going away. JC, quite jeering) Congratulations! I think. ;) CVR> One thing we're definitely doing is moving to a cloaked CVR> archive. Since we already distribute all archives out of CVR> HTTP, not FTP, we're working on a CGI that'll strip all CVR> e-mail information out of messages on the fly (among other CVR> things, like header cleanup and some trivial formatting CVR> fixes). The idea is simple -- we've finally hit the point CVR> where you can't put an e-mail address up on a public site CVR> under any cirucmstance safely, so we're having to move to a CVR> system where we simply don't do that. So these are public archives that need to be scrubbed, right? Until now, Mailman has taken the approach that public archives are feed right off the file system by the http server. We could still do that if we scrubbed the messages before we archived them, although that doesn't help with existing archives unless you re-generate them. So one question is: does the performance trade-off we made 5 years ago still make sense? Should we just be vetting all archives through a cgi, in which we can do fun stuff like cleanse it of email addresses? We'd obviously have to get rid of the easy access to the raw mbox file, so another question is whether that's still useful. Occasionally it's damn handy if you're moving a list or gathering statistics on it, but on the other hand, it's a rich source of addresses to mine. Again, if we scrubbed the messages pre-archiving we likely be ok. Also, what heuristic do you use to search for email addresses, and what do you scrub them with? Do you want to attempt to obscure the address (e.g. "barry--at--python--dot--org") or replace it altogether (e.g. "[hidden email address]"), or maybe just replace it with a truncation (e.g. "[localpart's email address]"). CVR> I think the Mailman stuff needs to think about this, also. It CVR> impacts the archiving setup and other issues, but the CVR> harvesters have hit the point where we simply can't risk CVR> disclosing that info. It creates other problems -- you can't CVR> see a posting in the archive and send email to that person CVR> with more questions (or answers), but that seems trivial CVR> compared to the problems the spammers are causing. It kind of plays into Reply-To: munging doesn't it? If you won't be able to reply to the original author, because we're anonymizing messages, then you might as well munge Reply-To: to go back to the list because that's the only posting address that makes sense. And what if the original poster isn't a member of the list? Or should Mailman get into the anonymous resender game? There's probably a lot we could do here, but given the political risks of anonymous resenders, do we even want go there? CVR> A secondary issue here is the problem of disclosing admins CVR> and admin addresses. Note that in MM2.1 we go about 1/2 way here. We include the obscured email addresses of the list owners as the text in a mailto: tag but we actually use the list-owner@ address as the mailto: target. That might not be enough though. When we actually have a Real Database backend we can keep a roster of email+realname and then just include the realname inside the href:mailto tag. CVR> I know we've hashed that through once, but we've come to the CVR> (somewhat reluctant) decision to whitelist all public, CVR> non-personal email addresses. We're going to be implementing CVR> TMDA to do this, and will be switching all admin to generic CVR> addresses that filter through TMDA, as well as things like CVR> postmaster@ and the like. While I hate making users jump CVR> through hoops to get through to a real person (for those that CVR> don't know, TMDA is an overt whitelist. If you're not on the CVR> whitelist, you get mail back telling you to take some action, CVR> and until you do, the mail isn't delivered), but the abuse by CVR> the spammers on admin addresses is now so bad I'm declaring CVR> defeat and going to the whitelist. Have you looked at SpamAssassin Chuq? It's really done wonders to reduce the amount of spam actually getting through any python.org or zope.org address. I know 'cause I see the daily reports of quarantined messages. Very few false positives too (usually it's email amongst our postmasters talking about spam or SA ;). I feel a lot better about this approach than TMDA'ing essential addresses like postmaster or mailman-owner. CVR> I'm going to look and see if I can interface TMDA to the CVR> subscriber databases so that subscribers are by definition CVR> whitelisted, but we've hit the poiint where we have to do CVR> this. I'm not happy about it, but the war is lost, I think. Sigh. CVR> So what he did was open up his address book and send his CVR> message to everyone in it. And he's running one of these new CVR> e-mail clients that happily caches addresses it sees in case CVR> you want them again. So all of the addresses of people CVR> posting to the mailing lists he subscribed to were in his CVR> address book cache, so when he grabbed his address book, he CVR> grabbed all of those addresses, too. Wonderful. I think this has been presaged by Klez which does essentially the same thing w/o human intervention or such good intent. ;) CVR> But now we're wondering if we have to go to some sort of CVR> address cloaking ON lists, maybe some kind of address CVR> remapping through the server for replies, something. And I'm CVR> gritting my teeth at the developers who created those CVR> @#$@$#@$#23 caches (which are nice in some ways) for not also CVR> creating some way to flag addresses as not CVR> cacheable. Because, IMHO, that'd solve this problem. Yup, but of course it implies that the clients play by the rules, and we know that they don't all, so the question is what we're willing to give up for the security of our online personas. Kinda mirrors today's large questions in the WoT(tm), eh? Maybe people are more willing to give up their rights than their conveniences for some added security. CVR> Are we hitting a point where mail list servers have to act as CVR> blind front ends for all of the subscribers, where replies CVR> are processed by those servers, and the server then takes on CVR> the job of acting as a troll-exterminator and spam blocker? CVR> And what does that really mean for things like Mailman? World domination of course. Because we /could/ add that stuff fairly easily if we had the resources to expend on it. Would it still be useable? For some audiences yes, others no. I'm fairly sure the kind of anonymizing we're talking about would never fly in the Python and Zope community, where as it's probably essential in a less cloistered environment like lists.apple.com. Which leads me to believe that we need to make it much easier to install themes or styles of lists, from the paranoid anonymizer to the laissez-faire discussion list. CVR> Happy Macworld Expo week, all. If you need me, I'll be in the CVR> war room, beating my head against a wall. Any chance you could make it down to DC for a side trip? We could have a Mailman hacking sprint over a few dozen steamed Maryland blue crabs and some cold ones. :) -Barry From barry@zope.com Tue Jul 16 22:42:41 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 16 Jul 2002 17:42:41 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... References: Message-ID: <15668.37713.552948.377@anthem.wooz.org> >>>>> "JWB" == John W Baxter writes: JWB> I think the issue is larger than just mailing lists: JWB> SMTP-based email will be unusable soon. The replacement will JWB> be something permission based with electronic signatures JWB> involved, and some TMDA-like way to get started conversing JWB> with someone. As mentioned before, SpamAssassin has gone a long way to making our python.org and zope.org addresses usable again. In fact, many of us are forwarding our mail /through/ python.org just so we don't have to install SA on our own machines. :) I'd really like to believe that a PKI based approach will work some day but I just seriously doubt it. It doesn't pass the "my mom can use it" test and I don't think it ever will. skeptical-ly y'rs, -Barry From barry@zope.com Tue Jul 16 22:46:02 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 16 Jul 2002 17:46:02 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... References: Message-ID: <15668.37914.173241.870536@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> Problem is, many users don't know how. And one could argue CVR> who ought to solve this problem. Should users be forced to CVR> jump through hoops to use a mail list safely? Or is it the CVR> user's decision how safe to be? Nope, I think it's the ISPs that will solve the problem, although it might be in ways mom-and-pops don't like. -Barry From jra@baylink.com Tue Jul 16 23:55:52 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 16 Jul 2002 18:55:52 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: ; from Chuq Von Rospach on Tue, Jul 16, 2002 at 10:58:00AM -0700 References: Message-ID: <20020716185552.54136@scfn.thpl.lib.fl.us> On Tue, Jul 16, 2002 at 10:58:00AM -0700, Chuq Von Rospach wrote: > One thing we're definitely doing is moving to a cloaked archive. Since we > already distribute all archives out of HTTP, not FTP, we're working on a CGI > that'll strip all e-mail information out of messages on the fly (among other > things, like header cleanup and some trivial formatting fixes). The idea is > simple -- we've finally hit the point where you can't put an e-mail address > up on a public site under any cirucmstance safely, so we're having to move > to a system where we simply don't do that. I'm voting in favor of the lynch mobs you mention later. No, I mean *really*. Two or three spammers getting shot; solve the problem right quick. :-) > I'm going to look and see if I can interface TMDA to the subscriber > databases so that subscribers are by definition whitelisted, but we've hit > the point where we have to do this. I'm not happy about it, but the war is > lost, I think. > > And speaking of privacy, harvesting and spamming, a new and disturbing thing > happened this weekend that I want to bring up -- one for which I have lots > of questions, but no real answers. A bunch of users on some of our mail > lists were spammed, and it became very clear very quickly that addresses > were harvested off of at least one of our mail lists. > > As you might guess, a lynch mob formed, and I lit the first virtual torch > and we all sharpened the pitchforks. Fortunately, the person who did it came > forward to me and admitted guilt, and explained what happened. > > And what happened is pretty damn disturbing. See, he had one of those "I > must tell the masses!" moments, where he finally felt it was time to send > out a call to arms on a subject he felt strongly about. > > So what he did was open up his address book and send his message to everyone > in it. And he's running one of these new e-mail clients that happily caches > addresses it sees in case you want them again. So all of the addresses of > people posting to the mailing lists he subscribed to were in his address > book cache, so when he grabbed his address book, he grabbed all of those > addresses, too. > > So we have a clear violation of our anti-harvesting rules -- yet he didn't > overtly harvest. He just grabbed what was in his address book at the time. > > This creates a major privacy quagmire. How do you set up rules for something > like that? Where does ownership and protection end? (I'm talking ethically, > not technically. I think we all realize that once someone posts email to a > list, you've given up control to anyone who doesn't feel obligated to follow > the rules). This wasn't a case of overtly violating the rules, but of a > piece of technology creating a situation where it wasn't understood there > were rules being violated. And this is a *perfect* case that supports what has been my assertion all along -- you non-Libertarians out there, cover your ears and sing -- *it's the recipient's problem*. This case is exactly the illustration I want: I couldn't have written one better from scratch. It's obvious that the answer is: setting up rules *would* *not* *have* *helped* *here*. Anyone who can demonstrate how it might have is welcome to post. If you send a message, it *has* to have a From address, and, to not violate the standards, that From address has to be valid. We all *want* that to be the case, right? So what are you going to do? Outlaw Outlook? :-) > I just don't know how to deal with the issues this address caching causes. The answer is that there is no answer. This might be the catalyst -- there had to be one eventually -- that inspires people to upgrade to Mail User Agents with sufficient flexibility to deal with problems like this. Automatically verifying PGP sigs as a whitelisting technique is merely one approach that springs to mind. There are many more. > Ultimately, we're going to have to rethink our "no harvesting" rules, and > likely also write disclaimers explaining what our limits are. We've actually > considered switching our lists to obscured addresses, turned that down as > being worse than the disease (for now). But now we're wondering if we have > to go to some sort of address cloaking ON lists, maybe some kind of address > remapping through the server for replies, something. And I'm gritting my > teeth at the developers who created those @#$@$#@$#23 caches (which are nice > in some ways) for not also creating some way to flag addresses as not > cacheable. Because, IMHO, that'd solve this problem. Yeah, but the Outhouse and OE teams aren't ever going there, and they're your problem. At some point, if you're going to *have* a mailnbox, you *have* to take responsibility for it. I stand on the non-enabler platform I've stood on before, as unpleasant as it is. In the end, I'm pretty sure there won't *be* any other options... > I'm curious what people think about this latest thing. The good news is he > wasn't trying to harvest us. The bad news is, he wasn't trying to harvest > us. And the b-tch of it is, I really don't have a comfortable feeling for > how to deal with this new situation yet... But I think it's an issue we have > to come to grips with. See above. ;-) > Are we hitting a point where mail list servers have to act as blind front > ends for all of the subscribers, where replies are processed by those > servers, and the server then takes on the job of acting as a > troll-exterminator and spam blocker? And what does that really mean for > things like Mailman? See less-above. I've had the same mailbox for 7 years; and *some* mailbox for just about 20. Until I was intemperate enough to put that email address into a poorly chosen slot, I got maybe a couple spams a day... and that address is on 5 or 6 domains, half a dozen web pages, and *ALL OVER* Usenet. And I *still* only got about half a dozen a day. Now, it's 25-50. People are known to say "it's not my fault", when, damnit, it *is* their fault. I'd say we need to make damned sure the problem is what we *think* it is before we "fix" that. Do you have documentary evidence, Chuq, that web harversters are the *only* way that *a majority* of the spam-complainers addresses could have gotten on those lists? Have you created test-accounts? Not 1 or 2; a couple dozen, in different places? > Happy Macworld Expo week, all. If you need me, I'll be in the war room, > beating my head against a wall. You've got a war room? Cool. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From bryanf@samurai.com Wed Jul 17 00:21:16 2002 From: bryanf@samurai.com (Bryan Fullerton) Date: Tue, 16 Jul 2002 19:21:16 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: Message-ID: On Tuesday, July 16, 2002, at 01:58 PM, Chuq Von Rospach wrote: > One thing we're definitely doing is moving to a cloaked archive. Since > we > already distribute all archives out of HTTP, not FTP, we're working on > a CGI > that'll strip all e-mail information out of messages on the fly (among > other > things, like header cleanup and some trivial formatting fixes). The > idea is > simple -- we've finally hit the point where you can't put an e-mail > address > up on a public site under any cirucmstance safely, so we're having to > move > to a system where we simply don't do that. > > I think the Mailman stuff needs to think about this, also. It impacts > the > archiving setup and other issues, but the harvesters have hit the point > where we simply can't risk disclosing that info. It creates other > problems > -- you can't see a posting in the archive and send email to that person > with > more questions (or answers), but that seems trivial compared to the > problems > the spammers are causing. I've had requests from customers for this as well. I'm fairly impartial as to whether it's done when the archive is displayed or when it's generated, but they a) want public archives, and b) don't want harvest-able addreses in them. Something like [address removed] would be fine, as long as the Real Name portion was (optionally?) preserved. Would probably also be a good idea for some private lists, to prevent more advanced harvesters (ie subscribe to list, grab all the addresses from the archives, unsubscribe - that can't be too hard to automate). I'm unsure about whether the obscurer should scan the body and nuke addresses there too - could be a PITA for technical lists (especially those discussing email issues!), but could be valuable for lists which REALLY want to protect subscribers. > A secondary issue here is the problem of disclosing admins and admin > addresses. I know we've hashed that through once, but we've come to the > (somewhat reluctant) decision to whitelist all public, non-personal > email > addresses. We're going to be implementing TMDA to do this, and will be > switching all admin to generic addresses that filter through TMDA, as > well > as things like postmaster@ and the like. While I hate making users jump > through hoops to get through to a real person (for those that don't > know, > TMDA is an overt whitelist. If you're not on the whitelist, you get mail > back telling you to take some action, and until you do, the mail isn't > delivered), but the abuse by the spammers on admin addresses is now so > bad > I'm declaring defeat and going to the whitelist. As mentioned by Barry, SpamAssassin good. > So what he did was open up his address book and send his message to > everyone > in it. And he's running one of these new e-mail clients that happily > caches > addresses it sees in case you want them again. So all of the addresses > of > people posting to the mailing lists he subscribed to were in his address > book cache, so when he grabbed his address book, he grabbed all of those > addresses, too. The perils of Ease of Use. I have a crapload of people in my OS X Address Book that Mail.app's been happily storing away for a rainy day. Luckily for them, I'm not likely to be excited enough about anything to add them all to an email. :) Bryan -- Bryan Fullerton http://bryanfullerton.com/ Core Competence uunet.ca!gts!cspace!bryanf Samurai Consulting Inc. From barry@zope.com Wed Jul 17 00:26:39 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 16 Jul 2002 19:26:39 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... References: Message-ID: <15668.43951.506378.458552@anthem.wooz.org> >>>>> "BF" == Bryan Fullerton writes: BF> The perils of Ease of Use. I have a crapload of people in my BF> OS X Address Book that Mail.app's been happily storing away BF> for a rainy day. Luckily for them, I'm not likely to be BF> excited enough about anything to add them all to an email. :) Just wait until I finish my solo album. Of course, you can all send me $15 now to hold your slot and get removed from my address book. :) -Barry From chuqui@plaidworks.com Wed Jul 17 00:34:17 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 16 Jul 2002 16:34:17 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <15668.37713.552948.377@anthem.wooz.org> Message-ID: On 7/16/02 2:42 PM, "Barry A. Warsaw" wrote: > JWB> be something permission based with electronic signatures > JWB> involved, and some TMDA-like way to get started conversing > JWB> with someone. > > As mentioned before, SpamAssassin has gone a long way to making our > python.org and zope.org addresses usable again. Agreed, for now. But SA is, frankly, a cold war situation of constant escalation. As you noted, Barry, some of you are forwarding through python.org to avoid having to install it, and spam assassin requires monitoring and upgrading. TMDA is sort of a fireaxe instead of a scalpel, but it won't require fairly frequent tweaking to keep ahead of the spammers, either. I think SA for user accounts and TMDA for public accounts is the proper setup if you can do it, but can you build Mailman to have a requirement for Spam Assassin to be installed? Or should this be something that Mailman takes responsibility for? That's really the question here. > I'd really like to believe that a PKI based approach will work some > day but I just seriously doubt it. It doesn't pass the "my mom can > use it" test and I don't think it ever will. Oh, um... -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ The first rule of holes: If you are in one, stop digging. From chuqui@plaidworks.com Wed Jul 17 00:35:28 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 16 Jul 2002 16:35:28 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <15668.37914.173241.870536@anthem.wooz.org> Message-ID: On 7/16/02 2:46 PM, "Barry A. Warsaw" wrote: > Nope, I think it's the ISPs that will solve the problem, although it > might be in ways mom-and-pops don't like. Actually, the mom and pops will love it. It's us geeks who whine on slashdot about stuff who'll hate it, because the ISPs will solve it for the moms and pops, and those of us capable of and willing to handle it ourselves won't have that option any more... -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Stress is when you wake up screaming and you realize you haven't fallen asleep yet. From jwblist@olympus.net Wed Jul 17 00:44:12 2002 From: jwblist@olympus.net (John W Baxter) Date: Tue, 16 Jul 2002 16:44:12 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <15668.37914.173241.870536@anthem.wooz.org> References: <15668.37914.173241.870536@anthem.wooz.org> Message-ID: At 17:46 -0400 7/16/2002, Barry A. Warsaw wrote: >>>>>> "CVR" == Chuq Von Rospach writes: > > CVR> Problem is, many users don't know how. And one could argue > CVR> who ought to solve this problem. Should users be forced to > CVR> jump through hoops to use a mail list safely? Or is it the > CVR> user's decision how safe to be? > >Nope, I think it's the ISPs that will solve the problem, although it >might be in ways mom-and-pops don't like. I don't think the ISPs *can* solve the problem in the near-to-medium-term future. [Longer term, with the demise of SMTP and its "everything open to all except for a few bandaids" approach, maybe.] At some point, the SpamAssassin/quarantine model breaks down...when you quarantine 10 large messages to let one smaller message go through, you're somewhere close to that point. As it is, we're busily installing four machines to do the work that one would do quite well in the absence of spammers (and they'll have help from another machine or two so that users can see their quarantined mail and rescue their false positives). And yes, SpamAssassin is part of that picture. Plus, I fear the "new breed" spammers (the ones who actually think their advertising is useful and welcome and only sent to opt-in lists, although they buy the lists from guys who [figuratively] sell them from under a trenchcoat at the entrance to a dark alley) will cause legislation to be passed forbidding filtering at the mail server level. It nearly happened last time around. Ah, well...we'll see how it goes. --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From chuqui@plaidworks.com Wed Jul 17 01:07:48 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 16 Jul 2002 17:07:48 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <15668.37417.657983.567997@anthem.wooz.org> Message-ID: On 7/16/02 2:37 PM, "Barry A. Warsaw" wrote: > CVR> the woodwork (I still run my Mailman box at home, however, so > CVR> I'm not going away. JC, quite jeering) > > Congratulations! I think. ;) Actually, yes. I won't be working 65+ hours a week any more, so I sort of get my life back, and may actually have time to think stuff through and do more than emergency patching... (for more, see ). Also means I can actually start some non-Apple hacking again, I hope. And what I'll be doing is lots of fun, although the next six weeks is going to be a crunch. Still doing email, just off building a new custom system for stuff I can't talk about... > CVR> One thing we're definitely doing is moving to a cloaked > CVR> archive. Since we already distribute all archives out of > So these are public archives that need to be scrubbed, right? Until > now, Mailman has taken the approach that public archives are feed > right off the file system by the http server. We could still do that > if we scrubbed the messages before we archived them, although that > doesn't help with existing archives unless you re-generate them. Here's why I won't do that. I want to keep ONE set of archives. You can't scrub those archives for two reasons. What if someone writes looking to get in contact with the author of a message? If the archive is scrubbed, that info is gone. And (god forbid), you get into a legal tangle? That's your legal record of what was said on the mail list and who said it. If you scrub it, and someone does something actionable or libelous and you get a court order to provide that data? You're hosed. On a more likely note -- I can see where you might want the option to show the archives unscrubbed to validated users, and only scrub the public archives. As paranoid as I'm being today, I'd STILL like to find a way to let subscribed users see the archives unscrubbed. Which you could do by setting a cookie that the CGI could accept and change it's behavior. So I really like leaving the archives unmodified, and doing the scrubbing via CGI. It also allows you do to other things, like header cleanups (and you could potentially let a user set a cookie to define minimal or full headers, say...) and some quickie cleanup against unwrapped text and some other incidental archive glitches. I come from a newspaper family, so I have a bias towards "you don't unpublish stuff, you don't change it once it's published". But I think there are good reasons to avoid sanitizing the archives, and instead sanitizing the delivery of those archives -- if only because if your policies change, all you need to change is the CGI. And it gives you the ability to set up different sets of abilities per user or per list if you want, too. > So one question is: does the performance trade-off we made 5 years ago > still make sense? Should we just be vetting all archives through a > cgi, in which we can do fun stuff like cleanse it of email addresses? One of the big things I dislike about Mhonarc is that archives are a rather low-usage system, but maintaining the Mhonarc index pages is rather intensive use of system resources. Sort of like usenet -- you do a lot of work on everything, in case someone wants anything. I think simply storing the archives and sanitizing on demand is lower overhead. It also means pipermail won't need ANY changes -- you simply feed it out through the CGI instead of directly, and everything magically sanitizes... > We'd obviously have to get rid of the easy access to the raw mbox > file, so another question is whether that's still useful. Honestly? I don't think so. I find them real kludgy. I ended up doing a new archiving system (one file per message) via a perl script. We're about to take our new search engine out of beta with the thing, finally. > Also, what heuristic do you use to search for email addresses, and > what do you scrub them with? Still being worked on. Right now, I'm basically doing a @nonwhitespace>. I don't know how strongly we'll refine it. >Do you want to attempt to obscure the > address (e.g. "barry--at--python--dot--org") Anything you programmatically obscure will be programmatically de-obscured. This technique is bogus and guaranteed to fail as soon as the spammers care enough. It's pretty clear even the "randomized obscuring" of slashdot is a failed technique, since spambots don't have to decode ALL of those formats, just some of them, and then cycle throug the site enough times.... Sorry, I find this is a false security. Makes the users feel better, accomplishes nothing useful, so in reality, users get lazy and careless. So to some degree, I feel it's worse than nothing. I'm planning on replacing email addresses with something useful like [email address deleted]. > CVR> disclosing that info. It creates other problems -- you can't > CVR> see a posting in the archive and send email to that person > CVR> with more questions (or answers), but that seems trivial > CVR> compared to the problems the spammers are causing. > > It kind of plays into Reply-To: munging doesn't it? If you won't be > able to reply to the original author, because we're anonymizing > messages, then you might as well munge Reply-To: to go back to the > list because that's the only posting address that makes sense. Yes (he says, grimacing). If you sanitize the archives, I don't think it affects the list. There are simply NO mailtos any more in the archives. If you go the step further and anonymize the postings ON the list, so subscriber email addresses simply are never shown to other subscribers under any circumstances (ugh. Urp. I can't believe I'm saying that. This is so anti-community it hurts), you have no choice and reply-to has to point to the list, since it's the only contact point left. If you instead turn the list server into a forwarding agent, as in: > Or should Mailman get into the anonymous resender game? There's > probably a lot we could do here, but given the political risks of > anonymous resenders, do we even want go there? Is it an anonymous remailer? We're making no pretense of anonymity here. We're acting as a forwarding agent, ala hotmail.com or mac.com. You mail to id13194@python.org, and it ends up in my mailbox. The fact that we're not explicitly denoting the real email address doesn't make us an anonymous remailer -- that'd be a policy issue, actually. I suppose you could take it that step further, but you could also set it up so validated subscribers could get to the real addresses. The model I'm thinking of is like many forum systems. If you're a guest, you don't get access to email info. If you're a subscriber, you log on, and they magically appear. In the case of mailing lists, since oyu lose control of the e-mail address once it leaves the site again, you handle this by only using the remailer address in mail that leaves the site, but a subscriber could go to the list system and look a user up. That gets us away from the politics of the anonymous stuff. > CVR> A secondary issue here is the problem of disclosing admins > CVR> and admin addresses. > > Note that in MM2.1 we go about 1/2 way here. We include the obscured > email addresses of the list owners as the text in a mailto: tag but we > actually use the list-owner@ address as the mailto: target. That > might not be enough though. When we actually have a Real Database > backend we can keep a roster of email+realname and then just include > the realname inside the href:mailto tag. I think six months ago it was enough. Now, I just don't think it is. Sigh. Grumble. > Have you looked at SpamAssassin Chuq? See my other message. SA is a good tool, if you have someone around willing to update it, monitor it, and make sure it stays up to date technologically with current releases that are updated to match the spammers changes. Do you want to require SA to be installed as a requirement for Mailman? What about sites where they don't have an admin to keep updating it? SA is only as good as the latest release blocks spam. So you have to keep updating it. Is that a realistic (and ultimately successful) strategy? I HATE WHITELISTS. But in the case of public addresses, I'm now convinced they're needed, because otherwise, you're committing to an ever-escalating war to stay ahead of the spammers. At best, that's going to cost continuing manpower and energy and be zero sum. You won't win, you simply continue surviving by sticking thumbs in the dike. > Very few false positives too (usually it's > email amongst our postmasters talking about spam or SA ;). All it takes is one. Have you seen these stories? >>Some stuff I've run across while digging out from being on vacation... >> >>An interesting take on collaborative anti-spam issues -- that forging email headers to test/validate an open relay is an illegal trespass on a mail server: >> >> >> >>Lincoln Stein saying the heck with it and deciding that manual filtering is better than the alternatives: >> >> >> >>And in case you didn't see it, cNet's article on why the RBLs are creating false positive problems. It really looks like the blackhole systems have now hit a critical mass where they're being noticed, and not favorably. The folks at SPEWS, if you read what has happened through their stuff and how their attitude leaked all over their responses, hasn't helped their cause much. >> >> >> >>Finally, another article, this from TidBits, about the growing problem of BAD filtering and false positives, and how it creates another set of (probably even worse) problems..... >> >> Also: >> http://news.com.com/2100-1023-943337.html?tag=fd_lede > CVR> @#$@$#@$#23 caches (which are nice in some ways) for not also > CVR> creating some way to flag addresses as not > CVR> cacheable. Because, IMHO, that'd solve this problem. > > Yup, but of course it implies that the clients play by the rules, and > we know that they don't all, so the question is what we're willing to > give up for the security of our online personas. Kinda mirrors > today's large questions in the WoT(tm), eh? Maybe people are more > willing to give up their rights than their conveniences for some added > security. Yeah. I see your Sigh and raise you. > World domination of course. Because we /could/ add that stuff fairly > easily if we had the resources to expend on it. Would it still be > useable? For some audiences yes, others no. I'm fairly sure the > kind of anonymizing we're talking about would never fly in the Python > and Zope community, where as it's probably essential in a less > cloistered environment like lists.apple.com. Which leads me to > believe that we need to make it much easier to install themes or > styles of lists, from the paranoid anonymizer to the laissez-faire > discussion list. You have nailed it on the head. Which is why I brought it up. Not because this is the way it has to be in the future, but because all this is making Mailman's job a whole lot more complex (we were whining about that at work today, or at least I was and everyone was nodding sympathetically and looking for an open window -- email used to be pretty easy and straight forward. And now.....). But not just because all this crap is getting in the way, but also that fixing this crap is overkill for some environments, and going to be NOT ENOUGH in others. > CVR> Happy Macworld Expo week, all. If you need me, I'll be in the > CVR> war room, beating my head against a wall. > > Any chance you could make it down to DC for a side trip? We could > have a Mailman hacking sprint over a few dozen steamed Maryland blue > crabs and some cold ones. :) Damn, that sounds good, but -- I've had to give up crab and shellfish (I've developed an intermitten sensitivity to it. Sigh!) and I'm staying in cupertino where I'll be manning the war room this week making sure buttons get pushed when they need pushed, and not a minute before.... -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ No! No! Dead girl, OFF the table! -- Shrek From philb@philb.us Wed Jul 17 01:11:31 2002 From: philb@philb.us (Phil Barnett) Date: Tue, 16 Jul 2002 20:11:31 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: References: Message-ID: <200207162011.31975.philb@philb.us> On Tuesday 16 July 2002 13:58, Chuq Von Rospach wrote: It's a thoughtful post, and includes many of the things I've been=20 contemplating myself, but I just had one thing to add about the list=20 management software becoming the arbiter of replies. > Are we hitting a point where mail list servers have to act as blind fro= nt > ends for all of the subscribers, where replies are processed by those > servers, and the server then takes on the job of acting as a > troll-exterminator and spam blocker? And what does that really mean for > things like Mailman? What would keep a spammer from using the reply mechanism to shuttle repli= es=20 back as if they were individual replies? I think that something like this would also need spam assassin and maybe = even=20 heuristics to help out. From bob@nleaudio.com Wed Jul 17 01:35:21 2002 From: bob@nleaudio.com (Bob Puff@NLE) Date: Tue, 16 Jul 2002 20:35:21 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... References: <15668.37914.173241.870536@anthem.wooz.org> Message-ID: <3D34BBC9.C0D8CB76@nleaudio.com> Not to get too far OT here but... I've seen the next generation of spammer software at work recently. Spammer's machine makes direct SMTP connection to my box, gives MY address as the FROM:, TO:, and REPLY-TO:. This bypasses all the open relay testing, and would only leave stuff like SA to detect it. Bob From chuqui@plaidworks.com Wed Jul 17 01:21:17 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 16 Jul 2002 17:21:17 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <20020716185552.54136@scfn.thpl.lib.fl.us> Message-ID: On 7/16/02 3:55 PM, "Jay R. Ashworth" wrote: > I'm voting in favor of the lynch mobs you mention later. > And this is a *perfect* case that supports what has been my assertion > all along -- you non-Libertarians out there, cover your ears and sing > -- *it's the recipient's problem*. This case is exactly the > illustration I want: I couldn't have written one better from scratch. But without rules, you can't teach the recipient what's right (with a cattle prod, if necessary), and without rules, the lynch mob has no binding authority. > It's obvious that the answer is: setting up rules *would* *not* *have* > *helped* *here*. Nope. But those rules are what allows you to go and make an example of the poor schmuck, in hopes that it'll keep the next person from making the same mistake. Wtihout the rules, there is no map you can use to teach people how to stay out of the tiger pits. > So what are you going to do? > > Outlaw Outlook? Don't blame outlook here. Lots of mail clients do this 'temporary caching'. > The answer is that there is no answer. The answer is there IS an answer. Just not a complete or fully satisfying one. The answer is multi-faceted: 1) rules that explicitly and unambiguously call out what is and isn't acceptable. 2) education systems to help users understand the situation and learn how to deal with it appropriately. 3) information that explains (and legally limits your liability for) the limits of what you can and can't do given all this technnology, so subscribers understand what you're doing and what you can't do anything about but (1) and (2) above. 4) a cattle prod for when all of the above fails. 5) patience of a saint, reaction times of a ranger. > Automatically verifying PGP sigs as a whitelisting technique is merely > one approach that springs to mind. There are many more. Sorry, doesn't really solve the problem. I posted a url to a note I wrote on this to barry a few minutes ago. > Yeah, but the Outhouse and OE teams aren't ever going there, and > they're your problem. Hint: this wasn't a windows box, and it wasn't a microsoft product. IT AIN'T MICROSOFT. Lots of clients do this now. > At some point, if you're going to *have* a mailnbox, you *have* to take > responsibility for it. Yes, but if you're going to distribute email, that doesn't remove your obligation to do what you can to protect the user from abuses in that distribution. BOTH sites and obligations and responsibilities. > Do you have documentary evidence, Chuq, that web harversters are the > *only* way that *a majority* of the spam-complainers addresses could > have gotten on those lists? Have you created test-accounts? Not 1 or > 2; a couple dozen, in different places? The person who did this has come clean to me. I know exactly what he did. It's about the only reason I've let him live. He hasn't always been, well, sending me christmas cards, but he's been fully cooperative. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ No! No! Dead girl, OFF the table! -- Shrek From chuqui@plaidworks.com Wed Jul 17 01:25:18 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 16 Jul 2002 17:25:18 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <200207162011.31975.philb@philb.us> Message-ID: On 7/16/02 5:11 PM, "Phil Barnett" wrote: > What would keep a spammer from using the reply mechanism to shuttle replies > back as if they were individual replies? It wouldn't. But as soon as that happens, that either gets blacklisted, or the reply address invalidated and the subscriber issued a replacement. The advantage being that if one subscriber gets harvested, ALL of them likely are, so the server can act as a protective chokepoint here. It's not so much we can stop it cold, but we can limit the exposure and protect users from the results of being harvested. It gives us better control and centralized power to protect users who struggle at protecting themselves. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Stress is when you wake up screaming and you realize you haven't fallen asleep yet. From chuqui@plaidworks.com Wed Jul 17 01:28:07 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 16 Jul 2002 17:28:07 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <3D34BBC9.C0D8CB76@nleaudio.com> Message-ID: On 7/16/02 5:35 PM, "Bob Puff@NLE" wrote: > I've seen the next generation of spammer software at work recently. Spammer's > machine makes direct SMTP connection to my box Actually, the REAL state of the art is that they look up your MX records, and do this to the HIGHEST ranked one (not the lowest). This is on the (it turns out, quite valid) assumption that it won't be spamblocked as well as the main MX relay is, but will be validated to forward stuff in to you. And where they're trying that, we're finding it works (grumble grr) damn well. Which means some of the assumptions we make on allowing, say, me on plaidworks to generate email as chuq@apple.com and forward it to someone at Apple are rapidly becoming obsolete, and how we design our backup MX systems need to be looked at, also. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ No! No! Dead girl, OFF the table! -- Shrek From philb@philb.us Wed Jul 17 01:31:37 2002 From: philb@philb.us (Phil Barnett) Date: Tue, 16 Jul 2002 20:31:37 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: References: Message-ID: <200207162031.37542.philb@philb.us> On Tuesday 16 July 2002 20:07, Chuq Von Rospach wrote: > The model I'm thinking of is like many forum systems. If you're a guest= , > you don't get access to email info. If you're a subscriber, you log on,= and > they magically appear. In the case of mailing lists, since oyu lose con= trol > of the e-mail address once it leaves the site again, you handle this by > only using the remailer address in mail that leaves the site, but a > subscriber could go to the list system and look a user up. That gets us > away from the politics of the anonymous stuff. It wouldn't be a bad idea, further to the above method, to have an option= at=20 the subscriber level that always stealth's their address, even if a=20 subscriber logs on. That gives the ultimate protection ability as an opt-= in.=20 If you don't opt in, other logged in subscribers see your real email addr= ess. Even though I like replyto munging, I know you don't. That would allow yo= u to=20 not replyto mung unless the user has gone totally stealth. From noreply@sourceforge.net Wed Jul 17 01:36:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 16 Jul 2002 17:36:14 -0700 Subject: [Mailman-Developers] [ mailman-Patches-582567 ] No Archive Message Message-ID: Patches item #582567, was opened at 2002-07-16 19:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=582567&group_id=103 Category: Web UI Group: None Status: Open Resolution: None Priority: 5 Submitted By: Susan Dridi (sdridi) Assigned to: Nobody/Anonymous (nobody) Summary: No Archive Message Initial Comment: If there are no messages in a private archive (a new list, for example), and if a user visits the archives, they are given a message with more path information than they need. For example, if I have a Mailman list called yippee and my user name is smith, the message displayed is: No file /yippee/ (/evenhigherdirectory/higherdirectory/smith/archives/private/yippee/) The path is generated by the "safetruefilename" variable which comes from: line 102 of Mailman/Cgi/private.py: path = os.environ.get('PATH_INFO') true_filename = os.path.join( mm_cfg.PRIVATE_ARCHIVE_FILE_DIR, true_path(path)) and line 194 of Mailman/Cgi/private.py except IOError: # Avoid cross-site scripting attacks safetruefilename = cgi.escape(true_filename) safepath = cgi.escape(path) print 'Content-type: text/html\n' print "

      Archive File Not Found

      " print "No file", safepath, '(%s)' % safetruefilename This is more information than a user can deduce from the URL. Users of a private list have the right to view info posted to the list. Unauthorized users shouldn't be able to learn directory structure of the host. This is not even information that the admin needs to debug anything - the admin ought to know where the archives are stored! By commenting out the variables after print "No file", safepath, the user is given a better info message, in this example, No file /yippee/ This may not be the best solution, but it works for my project:) -Susan ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=582567&group_id=103 From jra@baylink.com Wed Jul 17 01:49:19 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 16 Jul 2002 20:49:19 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: ; from Chuq Von Rospach on Tue, Jul 16, 2002 at 05:07:48PM -0700 References: <15668.37417.657983.567997@anthem.wooz.org> Message-ID: <20020716204919.07257@scfn.thpl.lib.fl.us> On Tue, Jul 16, 2002 at 05:07:48PM -0700, Chuq Von Rospach wrote: > in contact with the author of a message? If the archive is scrubbed, that > info is gone. And (god forbid), you get into a legal tangle? That's your > legal record of what was said on the mail list and who said it. If you scrub > it, and someone does something actionable or libelous and you get a court > order to provide that data? You're hosed. Nope. As long as your policies *do not change after* you receive such an order, you are not legally liable. You're not required even to *keep8 the archives by anything I know about -- you *are* familiar with the term "retention policy", right? :-) > I come from a newspaper family, so I have a bias towards "you don't > unpublish stuff, you don't change it once it's published". But I think there > are good reasons to avoid sanitizing the archives, and instead sanitizing > the delivery of those archives -- if only because if your policies change, > all you need to change is the CGI. And it gives you the ability to set up > different sets of abilities per user or per list if you want, too. Concur. Even though it's computationally expensive, bind as late as possible. > > We'd obviously have to get rid of the easy access to the raw mbox > > file, so another question is whether that's still useful. > > Honestly? I don't think so. I find them real kludgy. I ended up doing a new > archiving system (one file per message) via a perl script. We're about to > take our new search engine out of beta with the thing, finally. I hope you're de heirarchicalizing the directories. > > Also, what heuristic do you use to search for email addresses, and > > what do you scrub them with? > > Still being worked on. Right now, I'm basically doing a > @nonwhitespace> undary>. I don't know how strongly we'll refine it. Some places put spaces in mailbox names -- you'd better deal with quoted LHS's. > > It kind of plays into Reply-To: munging doesn't it? If you won't be > > able to reply to the original author, because we're anonymizing > > messages, then you might as well munge Reply-To: to go back to the > > list because that's the only posting address that makes sense. > > Yes (he says, grimacing). You feel my pain. :-) > If you sanitize the archives, I don't think it affects the list. There are > simply NO mailtos any more in the archives. > > If you go the step further and anonymize the postings ON the list, so > subscriber email addresses simply are never shown to other subscribers under > any circumstances (ugh. Urp. I can't believe I'm saying that. This is so > anti-community it hurts), you have no choice and reply-to has to point to > the list, since it's the only contact point left. Well, no: reply-to should be ADDRESS-REMOVED-FOR-SECURITY, and the pain should be pointed at the list admin. > If you instead turn the list server into a forwarding agent, as in: > > > Or should Mailman get into the anonymous resender game? There's > > probably a lot we could do here, but given the political risks of > > anonymous resenders, do we even want go there? > > Is it an anonymous remailer? We're making no pretense of anonymity here. > We're acting as a forwarding agent, ala hotmail.com or mac.com. You mail to > id13194@python.org, and it ends up in my mailbox. The fact that we're not > explicitly denoting the real email address doesn't make us an anonymous > remailer -- that'd be a policy issue, actually. I suppose you could take it > that step further, but you could also set it up so validated subscribers > could get to the real addresses. That would be a bit helpful, but *does* fundamentally change what the package is doing. > using the remailer address in mail that leaves the site, but a subscriber > could go to the list system and look a user up. That gets us away from the > politics of the anonymous stuff. But conversely, if subs can see real addresses in real messages, you're only one step away from the harvesting problem you mentioned earlier. > > Have you looked at SpamAssassin Chuq? > > See my other message. SA is a good tool, if you have someone around willing > to update it, monitor it, and make sure it stays up to date technologically > with current releases that are updated to match the spammers changes. Do you > want to require SA to be installed as a requirement for Mailman? What about > sites where they don't have an admin to keep updating it? You don't get what you don't pay for. Chuq, it's obvious to me that that's not a good enough answer for you. but I'm afraid, even though I know you've put at least one long reply to me into trying to explain why not in the past, that I still don't get it. Maybe it's me. So many things are just me. But *why isn't this the recipients' problem*? > > Very few false positives too (usually it's > > email amongst our postmasters talking about spam or SA ;). > All it takes is one. Have you seen these stories? I can synthesize some false-positive horror stories. But if you've got a couple handy -- with real termination notices -- let 'er rip. > > World domination of course. Because we /could/ add that stuff fairly > > easily if we had the resources to expend on it. Would it still be > > useable? For some audiences yes, others no. I'm fairly sure the > > kind of anonymizing we're talking about would never fly in the Python > > and Zope community, where as it's probably essential in a less > > cloistered environment like lists.apple.com. Which leads me to > > believe that we need to make it much easier to install themes or > > styles of lists, from the paranoid anonymizer to the laissez-faire > > discussion list. > > You have nailed it on the head. Which is why I brought it up. Not because > this is the way it has to be in the future, but because all this is making > Mailman's job a whole lot more complex (we were whining about that at work > today, or at least I was and everyone was nodding sympathetically and > looking for an open window -- email used to be pretty easy and straight > forward. And now.....). But not just because all this crap is getting in the > way, but also that fixing this crap is overkill for some environments, and > going to be NOT ENOUGH in others. Wow. Yeah, those two paragraphs capsulize it pretty well. Glad *I'm* not the architect. > > CVR> Happy Macworld Expo week, all. If you need me, I'll be in the > > CVR> war room, beating my head against a wall. > > > > Any chance you could make it down to DC for a side trip? We could > > have a Mailman hacking sprint over a few dozen steamed Maryland blue > > crabs and some cold ones. :) > > Damn, that sounds good, but -- I've had to give up crab and shellfish (I've > developed an intermitten sensitivity to it. Sigh!) and I'm staying in > cupertino where I'll be manning the war room this week making sure buttons > get pushed when they need pushed, and not a minute before.... You go, boy. Cheers, - jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From barry@zope.com Wed Jul 17 01:51:48 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 16 Jul 2002 20:51:48 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... References: <15668.37713.552948.377@anthem.wooz.org> Message-ID: <15668.49060.249023.394103@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> Agreed, for now. But SA is, frankly, a cold war situation of CVR> constant escalation. Yep. CVR> As you noted, Barry, some of you are forwarding through CVR> python.org to avoid having to install it, and spam assassin CVR> requires monitoring and upgrading. Indeed, although DeerSoft will probably make it mostly dead simple, at least for Windows users: http://www.deersoft.com/ CVR> TMDA is sort of a fireaxe instead of a scalpel, but it won't CVR> require fairly frequent tweaking to keep ahead of the CVR> spammers, either. True, that's a real problem. Note I already fight that battle with bounce messages, and they are /supposed/ to be playing by the rules. ;) CVR> I think SA for user accounts and TMDA for public accounts is CVR> the proper setup if you can do it, but can you build Mailman CVR> to have a requirement for Spam Assassin to be installed? Or CVR> should this be something that Mailman takes responsibility CVR> for? That's really the question here. It's a good question. There are patches on SF to integrate SA and Mailman which I haven't had time to look at, but no, I don't think SA should be a requirement. I /do/ think they ought to play very nicely together. >> I'd really like to believe that a PKI based approach will work >> some day but I just seriously doubt it. It doesn't pass the >> "my mom can use it" test and I don't think it ever will. CVR> Oh, um... CVR> Right on target. But of course it doesn't matter anyway because public key systems are hard enough for hardened geeks to use regularly, so there's no hope in hell my mom's ever going to use it (Aside: have y'all even tried to explain the basics of encryption, signatures, etc. to your mom or dad? I have. They're smart people, but not particularly computer literate. They're even fairly liberal/libertarian. It's hard to get past why they'd even /want/ to use it. Oh well, when we die off and our kids' kids are running the world, maybe it has a chance. ;) -Barry From barry@zope.com Wed Jul 17 01:54:43 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 16 Jul 2002 20:54:43 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... References: <15668.37914.173241.870536@anthem.wooz.org> Message-ID: <15668.49235.754682.247833@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: >> Nope, I think it's the ISPs that will solve the problem, >> although it might be in ways mom-and-pops don't like. CVR> Actually, the mom and pops will love it. It's us geeks who CVR> whine on slashdot about stuff who'll hate it, because the CVR> ISPs will solve it for the moms and pops, and those of us CVR> capable of and willing to handle it ourselves won't have that CVR> option any more... That's kind of what I meant by the "moms-and-pops", i.e. the little guys, anybody not on a big ISP. I predict that AOL, Microsoft, the cable companies, and the content industry will decide How It Shall Be -- likely involving secure hardware -- and we simply won't be able to (or want to) play by their rules. -Barry From jra@baylink.com Wed Jul 17 01:57:40 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 16 Jul 2002 20:57:40 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: ; from Chuq Von Rospach on Tue, Jul 16, 2002 at 05:21:17PM -0700 References: <20020716185552.54136@scfn.thpl.lib.fl.us> Message-ID: <20020716205740.62150@scfn.thpl.lib.fl.us> On Tue, Jul 16, 2002 at 05:21:17PM -0700, Chuq Von Rospach wrote: > On 7/16/02 3:55 PM, "Jay R. Ashworth" wrote: > > I'm voting in favor of the lynch mobs you mention later. > > > And this is a *perfect* case that supports what has been my assertion > > all along -- you non-Libertarians out there, cover your ears and sing > > -- *it's the recipient's problem*. This case is exactly the > > illustration I want: I couldn't have written one better from scratch. > > But without rules, you can't teach the recipient what's right (with a cattle > prod, if necessary), and without rules, the lynch mob has no binding > authority. Where, by "rules", here, we mean "rules about what it acceptable mail"? Why, that's up to the recipients. To quote Jubal Harshaw: "Who's name is on that envelope, Nurse? ... Oh: not yours." > > It's obvious that the answer is: setting up rules *would* *not* *have* > > *helped* *here*. > > Nope. But those rules are what allows you to go and make an example of the > poor schmuck, in hopes that it'll keep the next person from making the same > mistake. Wtihout the rules, there is no map you can use to teach people how > to stay out of the tiger pits. That sentence seems to assume that the majority of the people *falling in* the tarpits are people doing it by accident. I don' think that and I don't think *you* think that. When mail is outlawed, only outlaws will send mail. > > So what are you going to do? > > > > Outlaw Outlook? > > Don't blame outlook here. Lots of mail clients do this 'temporary caching'. Stipulated, and NS6 does it too, though I think that Moz may not. It *is* configurable, at least, in Netscape. I've never had to turn it off, cause none of my clients are that dumb. But Outhouse *did* originate the idea, so far as I'm aware. > > The answer is that there is no answer. > > The answer is there IS an answer. Just not a complete or fully satisfying > one. > > The answer is multi-faceted: > > 1) rules that explicitly and unambiguously call out what is and isn't > acceptable. > > 2) education systems to help users understand the situation and learn how to > deal with it appropriately. > > 3) information that explains (and legally limits your liability for) the > limits of what you can and can't do given all this technnology, so > subscribers understand what you're doing and what you can't do anything > about but (1) and (2) above. > > 4) a cattle prod for when all of the above fails. > > 5) patience of a saint, reaction times of a ranger. You forgot to capitalize that. :-) > > Automatically verifying PGP sigs as a whitelisting technique is merely > > one approach that springs to mind. There are many more. > > Sorry, doesn't really solve the problem. I posted a url to a note I wrote on > this to barry a few minutes ago. By which I meant, "sigs of people in your address book." No, this doesn't solve the "stupid user" problem... but you don't *solve* that with technology. You solve it with a LART. > > Yeah, but the Outhouse and OE teams aren't ever going there, and > > they're your problem. > > Hint: this wasn't a windows box, and it wasn't a microsoft product. IT AIN'T > MICROSOFT. Lots of clients do this now. Stipulated, but they're 80-90% of the market. I think even skewing for "non-Windoze users send more mail, you would still be about 70%, intuitively. > > At some point, if you're going to *have* a mailbox, you *have* to take > > responsibility for it. > > Yes, but if you're going to distribute email, that doesn't remove your > obligation to do what you can to protect the user from abuses in that > distribution. BOTH sites and obligations and responsibilities. Chasing spammers is one thing. Chasing people who directly harvest your listmanagement machine in person seems quite another. *That* you can't do on a case by case basis? Are you getting harvested every 5 minutes? > > Do you have documentary evidence, Chuq, that web harversters are the > > *only* way that *a majority* of the spam-complainers addresses could > > have gotten on those lists? Have you created test-accounts? Not 1 or > > 2; a couple dozen, in different places? > > The person who did this has come clean to me. I know exactly what he did. > It's about the only reason I've let him live. He hasn't always been, well, > sending me christmas cards, but he's been fully cooperative. No, I mean in other cases. You're using webharvesting, it seems, as your major motivation here; it doesn't seem to me -- please don't take this wrong -- that there's evidence that it's really a big enough problem to solve (for people who don't send 40M pieces of email an hour). Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From barry@zope.com Wed Jul 17 01:59:39 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 16 Jul 2002 20:59:39 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... References: <15668.37914.173241.870536@anthem.wooz.org> Message-ID: <15668.49531.411605.168297@anthem.wooz.org> >>>>> "JWB" == John W Baxter writes: JWB> I don't think the ISPs *can* solve the problem in the JWB> near-to-medium-term future. [Longer term, with the demise of JWB> SMTP and its "everything open to all except for a few JWB> bandaids" approach, maybe.] JWB> At some point, the SpamAssassin/quarantine model breaks JWB> down...when you quarantine 10 large messages to let one JWB> smaller message go through, you're somewhere close to that JWB> point. As it is, we're busily installing four machines to do JWB> the work that one would do quite well in the absence of JWB> spammers (and they'll have help from another machine or two JWB> so that users can see their quarantined mail and rescue their JWB> false positives). And yes, SpamAssassin is part of that JWB> picture. Some of the work the python.org postmaster (Greg Ward) is doing involves examining and rejecting messages during the SMTP dialog. The trick is to force them to do more work to deliver their spam, upping the costs of the sending host just enough for it to be not worth it. Unfortunately, I suspect our own costs will go up faster than theirs so we'll likely lose this battle too. But IMO, anything that isn't economics based will fail. JWB> Plus, I fear the "new breed" spammers (the ones who actually JWB> think their advertising is useful and welcome and only sent JWB> to opt-in lists, although they buy the lists from guys who JWB> [figuratively] sell them from under a trenchcoat at the JWB> entrance to a dark alley) will cause legislation to be passed JWB> forbidding filtering at the mail server level. It nearly JWB> happened last time around. Yup, but on the other side of the coin, they're getting sued and losing for not verifying their opt-in lists. But none of that matters either given the global nature of things. JWB> Ah, well...we'll see how it goes. can-i-be-a-rock-star-now?-ly y'rs, -Barry From bob@nleaudio.com Wed Jul 17 02:26:57 2002 From: bob@nleaudio.com (Bob Puff@NLE) Date: Tue, 16 Jul 2002 21:26:57 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... References: Message-ID: <3D34C7E1.FCDA98EB@nleaudio.com> > Actually, the REAL state of the art is that they look up your MX records, > and do this to the HIGHEST ranked one (not the lowest). This is on the (it > turns out, quite valid) assumption that it won't be spamblocked as well as > the main MX relay is, but will be validated to forward stuff in to you. And > where they're trying that, we're finding it works (grumble grr) damn well. Exactly. I didn't state that, but you put it well. But who cares if it's the primary MX or not? If it hits any of my MXs, it will be delivered. Bob From barry@zope.com Wed Jul 17 02:34:16 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 16 Jul 2002 21:34:16 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... References: <15668.37417.657983.567997@anthem.wooz.org> Message-ID: <15668.51608.174634.163001@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> Actually, yes. I won't be working 65+ hours a week any more, CVR> so I sort of get my life back, and may actually have time to CVR> think stuff through and do more than emergency CVR> patching... (for more, see CVR> ). Also CVR> means I can actually start some non-Apple hacking again, I CVR> hope. And what I'll be doing is lots of fun, although the CVR> next six weeks is going to be a crunch. Still doing email, CVR> just off building a new custom system for stuff I can't talk CVR> about... Very interesting, and congrats on getting your life back. Also, my apologies for not responding earlier, but I think you understand probably as well as anybody. :) > CVR> One thing we're definitely doing is moving to a cloaked > CVR> archive. Since we already distribute all archives out of > So these are public archives that need to be scrubbed, right? Until > now, Mailman has taken the approach that public archives are feed > right off the file system by the http server. We could still do that > if we scrubbed the messages before we archived them, although that > doesn't help with existing archives unless you re-generate them. CVR> Here's why I won't do that. I want to keep ONE set of CVR> archives. You can't scrub those archives for two CVR> reasons. What if someone writes looking to get in contact CVR> with the author of a message? If the archive is scrubbed, CVR> that info is gone. And (god forbid), you get into a legal CVR> tangle? That's your legal record of what was said on the mail CVR> list and who said it. If you scrub it, and someone does CVR> something actionable or libelous and you get a court order to CVR> provide that data? You're hosed. Excellent points all, I completely agree. CVR> On a more likely note -- I can see where you might want the CVR> option to show the archives unscrubbed to validated users, CVR> and only scrub the public archives. As paranoid as I'm being CVR> today, I'd STILL like to find a way to let subscribed users CVR> see the archives unscrubbed. Which you could do by setting a CVR> cookie that the CGI could accept and change it's behavior. Yup, all possible if we give up the notion of vending the public archives from disk. We pay in cpu, but oh well, that's cheap these days, isn't it? CVR> So I really like leaving the archives unmodified, and doing CVR> the scrubbing via CGI. It also allows you do to other things, CVR> like header cleanups (and you could potentially let a user CVR> set a cookie to define minimal or full headers, say...) and CVR> some quickie cleanup against unwrapped text and some other CVR> incidental archive glitches. CVR> I come from a newspaper family, so I have a bias towards "you CVR> don't unpublish stuff, you don't change it once it's CVR> published". But I think there are good reasons to avoid CVR> sanitizing the archives, and instead sanitizing the delivery CVR> of those archives -- if only because if your policies change, CVR> all you need to change is the CGI. And it gives you the CVR> ability to set up different sets of abilities per user or per CVR> list if you want, too. Again, excellent points. > So one question is: does the performance trade-off we made 5 years ago > still make sense? Should we just be vetting all archives through a > cgi, in which we can do fun stuff like cleanse it of email addresses? CVR> One of the big things I dislike about Mhonarc is that CVR> archives are a rather low-usage system, but maintaining the CVR> Mhonarc index pages is rather intensive use of system CVR> resources. Sort of like usenet -- you do a lot of work on CVR> everything, in case someone wants anything. I think simply CVR> storing the archives and sanitizing on demand is lower CVR> overhead. It also means pipermail won't need ANY changes -- CVR> you simply feed it out through the CGI instead of directly, CVR> and everything magically sanitizes... Yup. Wanna help write the script? > We'd obviously have to get rid of the easy access to the raw mbox > file, so another question is whether that's still useful. CVR> Honestly? I don't think so. I find them real kludgy. I ended CVR> up doing a new archiving system (one file per message) via a CVR> perl script. We're about to take our new search engine out of CVR> beta with the thing, finally. I find the mboxes really handy for gathering statistics, but maybe because Python has some really nice tools to troll through them (e.g. we use the python-list mbox to stress ZODB). And it's also handy if you move lists, but I think that's about it. I'm sure "regular users" wouldn't care if we hid the mboxes. BTW, that's all true even if you go to a one-file-per-message layout a la mh. > Also, what heuristic do you use to search for email addresses, and > what do you scrub them with? CVR> Still being worked on. Right now, I'm basically doing a CVR> @nonwhitespace> undary>. I don't know how strongly we'll refine it. Cool. >Do you want to attempt to obscure the > address (e.g. "barry--at--python--dot--org") CVR> Anything you programmatically obscure will be CVR> programmatically de-obscured. This technique is bogus and CVR> guaranteed to fail as soon as the spammers care enough. It's CVR> pretty clear even the "randomized obscuring" of slashdot is a CVR> failed technique, since spambots don't have to decode ALL of CVR> those formats, just some of them, and then cycle throug the CVR> site enough times.... CVR> Sorry, I find this is a false security. Makes the users feel CVR> better, accomplishes nothing useful, so in reality, users get CVR> lazy and careless. So to some degree, I feel it's worse than CVR> nothing. I'm planning on replacing email addresses with CVR> something useful like [email address deleted]. Agreed. > CVR> disclosing that info. It creates other problems -- you can't > CVR> see a posting in the archive and send email to that person > CVR> with more questions (or answers), but that seems trivial > CVR> compared to the problems the spammers are causing. > > It kind of plays into Reply-To: munging doesn't it? If you won't be > able to reply to the original author, because we're anonymizing > messages, then you might as well munge Reply-To: to go back to the > list because that's the only posting address that makes sense. CVR> Yes (he says, grimacing). :) CVR> If you sanitize the archives, I don't think it affects the CVR> list. There are simply NO mailtos any more in the archives. CVR> If you go the step further and anonymize the postings ON the CVR> list, so subscriber email addresses simply are never shown to CVR> other subscribers under any circumstances (ugh. Urp. I can't CVR> believe I'm saying that. This is so anti-community it hurts), CVR> you have no choice and reply-to has to point to the list, CVR> since it's the only contact point left. Yup. CVR> If you instead turn the list server into a forwarding agent, CVR> as in: > Or should Mailman get into the anonymous resender game? There's > probably a lot we could do here, but given the political risks of > anonymous resenders, do we even want go there? CVR> Is it an anonymous remailer? We're making no pretense of CVR> anonymity here. We're acting as a forwarding agent, ala CVR> hotmail.com or mac.com. You mail to id13194@python.org, and CVR> it ends up in my mailbox. The fact that we're not explicitly CVR> denoting the real email address doesn't make us an anonymous CVR> remailer -- that'd be a policy issue, actually. I suppose you CVR> could take it that step further, but you could also set it up CVR> so validated subscribers could get to the real addresses. CVR> The model I'm thinking of is like many forum systems. If CVR> you're a guest, you don't get access to email info. If you're CVR> a subscriber, you log on, and they magically appear. In the CVR> case of mailing lists, since oyu lose control of the e-mail CVR> address once it leaves the site again, you handle this by CVR> only using the remailer address in mail that leaves the site, CVR> but a subscriber could go to the list system and look a user CVR> up. That gets us away from the politics of the anonymous CVR> stuff. Hmm, maybe you're right. You've got to keep those random forwarding addresses alive for a long (configurable) time so that replies will continue to work. CVR> You have nailed it on the head. Which is why I brought it CVR> up. Not because this is the way it has to be in the future, CVR> but because all this is making Mailman's job a whole lot more CVR> complex (we were whining about that at work today, or at CVR> least I was and everyone was nodding sympathetically and CVR> looking for an open window -- email used to be pretty easy CVR> and straight forward. And now.....). But not just because all CVR> this crap is getting in the way, but also that fixing this CVR> crap is overkill for some environments, and going to be NOT CVR> ENOUGH in others. Exactly. Here's the trick: for those who it is not enough, get them to pay enough for it that it could sustain a business. That way, you keep the overkill crowd happy with the free stuff, which the super paranoid help subsidize. CVR> Damn, that sounds good, but -- I've had to give up crab and CVR> shellfish (I've developed an intermitten sensitivity to CVR> it. Sigh!) and I'm staying in cupertino where I'll be manning CVR> the war room this week making sure buttons get pushed when CVR> they need pushed, and not a minute before.... Ah too bad (about both!). The offer of some cold ones (of a liquid of your choice) stands if you ever make it to DC. :) -Barry From barry@zope.com Wed Jul 17 02:38:50 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 16 Jul 2002 21:38:50 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... References: <200207162011.31975.philb@philb.us> Message-ID: <15668.51882.482298.444165@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> It's not so much we can stop it cold, but we can limit the CVR> exposure and protect users from the results of being CVR> harvested. It gives us better control and centralized power CVR> to protect users who struggle at protecting themselves. And a centralized point of attack, either technologically or legally. -Barry From chuqui@plaidworks.com Wed Jul 17 03:34:32 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 16 Jul 2002 19:34:32 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: Message-ID: On 7/16/02 4:44 PM, "John W Baxter" wrote: > I don't think the ISPs *can* solve the problem in the near-to-medium-term > future. [Longer term, with the demise of SMTP and its "everything open to > all except for a few bandaids" approach, maybe.] Me, I'm just not that worried about this idea, any more than I worry about the 'we simply need to redo e-mail so you pay to send things' -- because any NEW system is going to have to be backwards compatible with the old system for a significant period of time, iether directly or through some kind of gateway system -- so there's a good period of time for the lot of us to find ways of dealing with it. And don't forget, even the big ISPs use off the shelf tools like sendmail, postfix, etc. if they really want to build customized systems, it'll be really tough (and expensive) to do so without the tools they bring in from the open source community, and as big as any of the ISPs are, whatever protocols they create will have to be open at some level, because while MSN is huge and AOL is huge, if AOL can't talk to MSN and MSN can't talk to AOL, the protocol will fail. And whatever protocol they build, open source can build something that works with it. If they can reverse engineer samba, I'm not worried about e-mail protocols. And given that most of the big boys build their systems (increasingly) on linux and use open source extensively, I think the "big boys will lock us all out" is a strawman. Which doesn't mean I don't think we should not be vigilant, but... > At some point, the SpamAssassin/quarantine model breaks down... Yeah. When you're on deadline, and the admin is on vacation. > As it is, we're busily installing four > machines to do the work that one would do quite well in the absence of > spammers (and they'll have help from another machine or two so that users > can see their quarantined mail and rescue their false positives). And yes, > SpamAssassin is part of that picture. Yup. That setup is fairly typical for high volume email systems these days. But a number of the big e-mail systems who's admins I talk to are seeing as much as 30% of the email being sent to the system rejected as spam, and the numbers are growing. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after From chuqui@plaidworks.com Wed Jul 17 03:57:44 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 16 Jul 2002 19:57:44 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <20020716204919.07257@scfn.thpl.lib.fl.us> Message-ID: On 7/16/02 5:49 PM, "Jay R. Ashworth" wrote: > On Tue, Jul 16, 2002 at 05:07:48PM -0700, Chuq Von Rospach wrote: >> in contact with the author of a message? If the archive is scrubbed, that >> info is gone. And (god forbid), you get into a legal tangle? > the archives by anything I know about -- you *are* familiar with the > term "retention policy", right? :-) True, but let me rephrase with the situation I should have used in the first place. Two of your users get into a fight on the list. One of them finally says some variation of "you are a dead man". Three weeks later, the other guy's house burns down because of arson, and all you have is an archive with no identifying information in it.... >> archiving system (one file per message) via a perl script. We're about to >> take our new search engine out of beta with the thing, finally. > > I hope you're de heirarchicalizing the directories. I'm confused. What are you suggesting? (FWIW, our structure is /yyyy/mm/dd/) > Some places put spaces in mailbox names -- you'd better deal with > quoted LHS's. I know. That's one of the things we need to evaluate still. >> If you go the step further and anonymize the postings ON the list, so >> subscriber email addresses simply are never shown to other subscribers under >> any circumstances (ugh. Urp. I can't believe I'm saying that. This is so >> anti-community it hurts), you have no choice and reply-to has to point to >> the list, since it's the only contact point left. > > Well, no: reply-to should be ADDRESS-REMOVED-FOR-SECURITY, and the pain > should be pointed at the list admin. No, I don't agree. You still, at least in theory, want users to have a conversation. But by cloaking on the address, you are, effectively, forcing that conversation to go through the list under all circumstances. So reply-to should go to the list, not the admin. >> that step further, but you could also set it up so validated subscribers >> could get to the real addresses. > > That would be a bit helpful, but *does* fundamentally change what the > package is doing. Yeah. It's a fairly significant hunk o' code, AND it requires, basically, that '*@some.domain' be forwarded to the server for processing. Or at a very minimum, an LDAP lookup for valid addresses, because trying to manage that as an alias file or some static structure would be deadly. >> using the remailer address in mail that leaves the site, but a subscriber >> could go to the list system and look a user up. That gets us away from the >> politics of the anonymous stuff. > > But conversely, if subs can see real addresses in real messages, you're > only one step away from the harvesting problem you mentioned earlier. Yes, but it keeps it out of those !@#$@%@$#@!@#@! automatic caches. And in theory, you could tell if someone started harvesting, because the system could be taught to watch for systematic walks through the database. > Chuq, it's obvious to me that that's not a good enough answer for you. > but I'm afraid, even though I know you've put at least one long reply > to me into trying to explain why not in the past, that I still don't > get it. > > Maybe it's me. No, it's that we're still hashing things out, and a number of things, in general, just aren't clear (or resolved) > But *why isn't this the recipients' problem*? Or more correctly, why isn't it ONLY the recipient's problem? Two reasons: 1) I (as the list admin to the recipient) am offering a service. I strongly believe that if I'm offering a service, I have an ethical (if not legal) responsibility to make that service as problem free as possible. To me, the alternative is the same as selling toasters that aren't US approved because I feel it's the buyer's responsibilty to make sure they aren't electrocuted. Now, I think it's ALSO the buyer's responsibilty to be aware of the risk of electrocution, but that doesn't remove the responsibility from me to not sell them a cheap, shoddy toaster. 1.5) Having said that as list admin -> recipient, iterate and I feel the same is true of "mail list developer" -> list admin. Because... 2) I feel it is a responsibility of the experts to do what they can to take care of the not-so-experts. Since we (the developers) are the experts. We have the ability to build systems to deal with this, and so I feel we should, so that people who aren't as capable can benefit as well. Saying "it's his responsibility" only works as long as "he" can ALSO do what we do and knows what we know, and that's clearly not a true assumption. So saying that is really not assigning responsibility, but ducking it. That doesn't means we ought to solve all of the problems in the universe, but we are the folks most qualified to understand and solve these things -- so we should. It's easy to say "every man for themselves" when you're at the top of the food chain, because you CAN do it. But I think it avoids the real responsibility by making the false assumption that it's just as simple for others to do it, too. If it was, we wouldn't be at the top of the food chain, wouldn't we? Instead, I see it as a rationalization to avoid having to do the work needed so that others can also use it. If everyone had the same skill set, Jay, I'd agree with you. But they don't. And the nice thing is, some of those people are at the top of the food chain in other skillsets, and we get to benefit from what they know. And if they were all off trying to learn what we already know, they probably wouldn't have the time or energy to build things in their expertise we can benefit from, so it all evens out at the end. Imagine if Tim Berners-Lee was too busy writing spamblock software to invent the browser.... I see us leveraging our expertise as a way to make sure some other expert gets to leverage their expertise so that whatever they can invent actually gets invented -- rather than sidetracked by something we could have saved them from but didn't, because we were self-focused. >> All it takes is one. Have you seen these stories? > > I can synthesize some false-positive horror stories. But if you've got > a couple handy -- with real termination notices -- let 'er rip. I can't give any definite examples to protect the people involved, but I know of a couple of people who've had their careers significantly impacted because of this stuff. Maybe not fatal, but third degree burns. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ He doesn't have ulcers, but he's a carrier. From chuqui@plaidworks.com Wed Jul 17 04:11:43 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 16 Jul 2002 20:11:43 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <20020716205740.62150@scfn.thpl.lib.fl.us> Message-ID: On 7/16/02 5:57 PM, "Jay R. Ashworth" wrote: >> But without rules, you can't teach the recipient what's right (with a cattle >> prod, if necessary), and without rules, the lynch mob has no binding >> authority. > > Where, by "rules", here, we mean "rules about what it acceptable mail"? Well, we're talking past each other a little bit, but at the same time, not. Because I think there's still a responsibility on the list admin, because when someone signs up for a list, they're delegating some responsibility over who can access their mailbox to the owner of the list, and the agreement between the two are the rules set up about acceptable content. So you can't duck some responsibility here. Oh, by the way, there's few ways guaranteed to PISS ME OFF more than someone who signs up for a mailing list, and then starts bouncing selected pieces of the mail because of filtering systems. Which usually happens because their admin installs stupid filters... (I don't care if you throw them away, but I hate showing up in the morning to 50 bounce messages because of some flakey content filter...) Right now, for instance, one of the lists at apple is having a discussion about coding problems. And the user starting it served up a code fragment that included: int xxx = 0 [...] You can imagine the chaos that ensues among the STUPID IS FILTER IDIOTS who do overly simplistic filtering and assume it actually does something useful. But I'm not bitter. (and I'll be curious to see just how many bounces that I or barry see from THAT simple notation.....) > That sentence seems to assume that the majority of the people *falling > in* the tarpits are people doing it by accident. I don' think that > and I don't think *you* think that. Yes, I do. Since I (for the most part, most of the time) have the felons locked out of the system pretty well, most of the people who cause problems on my systems aren't trying to f--k with the system, they're people who are oblivious, confused, or misguided. Even the spammer over the weekend meant no harm, which doesn't mean harm wasn't caused. It was a classiv case of "my cause is so important it justifies doing this" -- which, he found out the hard way, a few hundred people disagreed with him over. > By which I meant, "sigs of people in your address book." No, this > doesn't solve the "stupid user" problem... but you don't *solve* that > with technology. > > You solve it with a LART. Sometimes, the best solution is a public flogging, to teach everyone else to be more careful next time. But if you overdo it, people tune you out, too. > Stipulated, but they're 80-90% of the market. I think even skewing for > "non-Windoze users send more mail, you would still be about 70%, > intuitively. We're working on that (a quiet voice whispers: "but a f---ing mac already! It has unix inside for all you geeks, too!") > Chasing people who directly harvest your listmanagement machine in > person seems quite another. > > *That* you can't do on a case by case basis? Are you getting harvested > every 5 minutes? You want to find out? Create a honeypot. Put some email addresses on it. Attach it to your home page. See how quickly you start getting e-mail to those addresses. You'll usually find the answer is "days". Once in a while, it's "hours". > No, I mean in other cases. You're using webharvesting, it seems, as > your major motivation here; it doesn't seem to me -- please don't take > this wrong -- that there's evidence that it's really a big enough > problem to solve (for people who don't send 40M pieces of email an > hour). I don't think you're looking close enough. Run a few honeypot tests and see how often people sneak a peek at YOUR system. On mine, it's a few days. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Yes, I am an agent of Satan, but my duties are largely ceremonial. From jra@baylink.com Wed Jul 17 05:22:53 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 17 Jul 2002 00:22:53 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: ; from Chuq Von Rospach on Tue, Jul 16, 2002 at 07:57:44PM -0700 References: <20020716204919.07257@scfn.thpl.lib.fl.us> Message-ID: <20020717002253.14548@scfn.thpl.lib.fl.us> On Tue, Jul 16, 2002 at 07:57:44PM -0700, Chuq Von Rospach wrote: > On 7/16/02 5:49 PM, "Jay R. Ashworth" wrote: > > On Tue, Jul 16, 2002 at 05:07:48PM -0700, Chuq Von Rospach wrote: > >> in contact with the author of a message? If the archive is scrubbed, that > >> info is gone. And (god forbid), you get into a legal tangle? > > > the archives by anything I know about -- you *are* familiar with the > > term "retention policy", right? :-) > > True, but let me rephrase with the situation I should have used in the first > place. Two of your users get into a fight on the list. One of them finally > says some variation of "you are a dead man". Three weeks later, the other > guy's house burns down because of arson, and all you have is an archive with > no identifying information in it.... Well, ok... but in a case like that, your mailer logs would likely have the appropriate information. But still, as rare as such a circumstance is, I don't see that you have any moral obligation to be *that* prepared. > >> archiving system (one file per message) via a perl script. We're about to > >> take our new search engine out of beta with the thing, finally. > > > > I hope you're de heirarchicalizing the directories. > > I'm confused. What are you suggesting? > > (FWIW, our structure is /yyyy/mm/dd/) That answers my question: I *knew* you knew better than to throw 30k files in one directory... > > Some places put spaces in mailbox names -- you'd better deal with > > quoted LHS's. > > I know. That's one of the things we need to evaluate still. Mutt's highlighting regexes are pretty decent, but I don't know that *any* RE can match both quoted and non-quoted mailbox names reliably. There's an argument going on somewhere else right now -- I thought it was bugtraq, but I seem to have misplaced the message -- about whether email addresses can have an RHS that terminates in a . The poster says no way, I say that 2821 and 1034/5 say yes. > > Well, no: reply-to should be ADDRESS-REMOVED-FOR-SECURITY, and the pain > > should be pointed at the list admin. > > No, I don't agree. You still, at least in theory, want users to have a > conversation. But by cloaking on the address, you are, effectively, forcing > that conversation to go through the list under all circumstances. So > reply-to should go to the list, not the admin. No, I was merely trying to avoid people getting in the habit of replying to lists; I disagree with munging even here. It sets a bad example. But I'm a purist, and don't have to catch the bullets, so what do I know? > >> that step further, but you could also set it up so validated subscribers > >> could get to the real addresses. > > > > That would be a bit helpful, but *does* fundamentally change what the > > package is doing. > > Yeah. It's a fairly significant hunk o' code, AND it requires, basically, > that '*@some.domain' be forwarded to the server for processing. Or at a very > minimum, an LDAP lookup for valid addresses, because trying to manage that > as an alias file or some static structure would be deadly. I might have gotten list (ok, I was trying to type ' l o s t ' there, but my hands refuse to cooperate; hell with it, it's a good pun) here... > >> using the remailer address in mail that leaves the site, but a subscriber > >> could go to the list system and look a user up. That gets us away from the > >> politics of the anonymous stuff. > > > > But conversely, if subs can see real addresses in real messages, you're > > only one step away from the harvesting problem you mentioned earlier. > > Yes, but it keeps it out of those !@#$@%@$#@!@#@! automatic caches. And in > theory, you could tell if someone started harvesting, because the system > could be taught to watch for systematic walks through the database. And you could actually verp the addresses, if you had enough horsepower, making 'backtracing', per se, unnecessary -- you'd *know* who sent the mail. Debugging, of course, would be murder, and admin-dependent; you could no longer do it from outside. > > Chuq, it's obvious to me that that's not a good enough answer for you. > > but I'm afraid, even though I know you've put at least one long reply > > to me into trying to explain why not in the past, that I still don't > > get it. > > > > Maybe it's me. > > No, it's that we're still hashing things out, and a number of things, in > general, just aren't clear (or resolved) Ok. I really *did* think it was just me. Glad to hear you don't. (You have, IIRC, in the past. ;-) > > But *why isn't this the recipients' problem*? > > Or more correctly, why isn't it ONLY the recipient's problem? Point. > Two reasons: > > 1) I (as the list admin to the recipient) am offering a service. I strongly > believe that if I'm offering a service, I have an ethical (if not legal) > responsibility to make that service as problem free as possible. To me, the > alternative is the same as selling toasters that aren't UL approved because > I feel it's the buyer's responsibilty to make sure they aren't electrocuted. Hmmm... the difference in degree *is* a difference in sorts, IMHO (OC spray isn't regulated nearly as severly as guns; you can't kill people with it)... but go on: > Now, I think it's ALSO the buyer's responsibilty to be aware of the risk of > electrocution, but that doesn't remove the responsibility from me to not > sell them a cheap, shoddy toaster. Stipulated. But I don't believe that the toaster *is* cheap and shoddy -- ie: that it's *your* responsibility -- merely because people break into your house, and jam oversized bagels into your toaster repeatedly until it won't hold toast anymore. > 1.5) Why I love geeks. ;-) > Having said that as list admin -> recipient, iterate and I feel the > same is true of "mail list developer" -> list admin. Because... > > 2) I feel it is a responsibility of the experts to do what they can to take > care of the not-so-experts. Since we (the developers) are the experts. We > have the ability to build systems to deal with this, and so I feel we > should, so that people who aren't as capable can benefit as well. Saying > "it's his responsibility" only works as long as "he" can ALSO do what we do > and knows what we know, and that's clearly not a true assumption. So saying > that is really not assigning responsibility, but ducking it. That doesn't > means we ought to solve all of the problems in the universe, but we are the > folks most qualified to understand and solve these things -- so we should. Except that the spam isn't the *problem*. The *spammers* are. Even when they get unreasonably strident, and scream for all the wrong reasons -- and they so -- I still back the Second Amendment absolutists, because history has proven that they *put that amendment in there for a reason*. The circumstances are much the same here. If we relieve the pain on the recipients for free, then they will *never* have an incentive to stop the problem at it's source. And I don't believe that anyone can inflict that pain on the spammers like an aroused citizenry. It is largely because of RMS' intransigience on many points related to Free Software that we have most of it, and most particularly Linux -- I really don't believe it would have happened at all except for the developer-protection provided by the GPL. Sometimes a cigar *is* just a cigar. Sometimes, you've got to let junior take the fall. > It's easy to say "every man for themselves" when you're at the top of the > food chain, because you CAN do it. But I think it avoids the real > responsibility by making the false assumption that it's just as simple for > others to do it, too. If it was, we wouldn't be at the top of the food > chain, wouldn't we? Instead, I see it as a rationalization to avoid having > to do the work needed so that others can also use it. Not at all. It's not a question of ease. Undertaking responsibility is not easy. Probably the worst thing is taking a stand that so strongly resembles merely a mediocre excuse for laziness. But, to coin a phrase, I Am Not Making This Up. Someone has to fix the problem. It has been proven to my satisfaction that the technologists can't: it's not a technology-fix problem (so few 'problems' are). Someone has to get *pissed*. That'd be the people with the mailboxes, Bob. > If everyone had the same skill set, Jay, I'd agree with you. But they don't. > And the nice thing is, some of those people are at the top of the food chain > in other skillsets, and we get to benefit from what they know. And if they > were all off trying to learn what we already know, they probably wouldn't > have the time or energy to build things in their expertise we can benefit > from, so it all evens out at the end. I understand what you mean... but I still think you're shooting at the wrong target. > Imagine if Tim Berners-Lee was too busy writing spamblock software to invent > the browser.... I see us leveraging our expertise as a way to make sure some > other expert gets to leverage their expertise so that whatever they can > invent actually gets invented -- rather than sidetracked by something we > could have saved them from but didn't, because we were self-focused. Fine. But this isn't procmail, nor SpamAssassin; they're at the other end of the hall; third and fifth doors on the right, respectively. This is a mailing list program. Put in hooks for such things, fine. Recommend them, great. Even automatically install them. But, please: mechanism, not policy. It's difficult to implement, but I think it's essential. > >> All it takes is one. Have you seen these stories? > > > > I can synthesize some false-positive horror stories. But if you've got > > a couple handy -- with real termination notices -- let 'er rip. > > I can't give any definite examples to protect the people involved, but I > know of a couple of people who've had their careers significantly impacted > because of this stuff. Maybe not fatal, but third degree burns. The topic being false-positive-ly blocked "spam", aren't those evidence for the prosecution, not the defense? Letting spam through likely only gets you yelled at; accidentally blocking important stuff gets you burned. We are on the critical path, folks. I know you know that, but the explicit reminder isn't going to get me fired. Fail-safe isn't just for aerospace anymore. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From jwblist@olympus.net Wed Jul 17 05:25:44 2002 From: jwblist@olympus.net (John W Baxter) Date: Tue, 16 Jul 2002 21:25:44 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <20020716204919.07257@scfn.thpl.lib.fl.us> References: <15668.37417.657983.567997@anthem.wooz.org> <20020716204919.07257@scfn.thpl.lib.fl.us> Message-ID: At 20:49 -0400 7/16/2002, Jay R. Ashworth wrote: >But *why isn't this the recipients' problem*? Because the recipient gives up, and takes her ISP payments elsewhere, or really gives up and takes them nowhere (which I'm tempted to do myself when I retire). --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From claw@kanga.nu Wed Jul 17 05:36:52 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 16 Jul 2002 21:36:52 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: Message from Chuq Von Rospach of "Tue, 16 Jul 2002 10:58:00 PDT." References: Message-ID: <21545.1026880612@kanga.nu> On Tue, 16 Jul 2002 10:58:00 -0700 Chuq Von Rospach wrote: > First, a minor announcement. I'm no longer in charge of the mailing > lists at apple, sort of. We've hired a person full-time, and he's been > taking over the lists server as his full-time responsibility, allowing > me to go off and work on other projects. I'm still in the loop, just > not "it". I'm still going to be heavily involved as we move that box > to Mailman 2.1, and after that, probably fade a bit more into the > woodwork (I still run my Mailman box at home, however, so I'm not > going away. JC, quite jeering) > ... to do what we can to make sure people who post to the mailing > lists don't get harvested. You realise that subscribed robots on lists are going to be the next SPAMmer trick? Of course they're easily defeated with an enforced moderated first post, but 'net-wide that's going to be a painful evolution. > A secondary issue here is the problem of disclosing admins and admin > addresses. I know we've hashed that through once, but we've come to > the (somewhat reluctant) decision to whitelist all public, > non-personal email addresses. We're going to be implementing TMDA to > do this... Actually it got very little discussion beyond the commentary that many/most of the valid mail to -owner and -admin is from member's non-subscribed addresses (even more likely given plus addressing). TMDA seems to work well tho for an -owner and -admin filter. > ... and will be switching all admin to generic addresses that filter > through TMDA, as well as things like postmaster@ and the like. Good idea. I've not moved over postmaster and webmaster. > I'm going to look and see if I can interface TMDA to the subscriber > databases so that subscribers are by definition whitelisted... It already can plug into Mailman's member roster in config.db. Generically extending that to plug, say, into an externally abstracted interface shouldn't be too difficult. What I've been poking at here is having TMDA call an external tool, passing it the address to be verified along with the To: address. The external tool would then do whatever (eg SQL query, LDAP lookup, poke into config.db, etc) and exit with an appropriate return code. Should work fairly well, especially for those cases where the authentication data is not local. > ... but we've hit the poiint where we have to do this. I'm not happy > about it, but the war is lost, I think. Or even close to being over. > And speaking of privacy, harvesting and spamming, a new and disturbing > thing happened this weekend that I want to bring up -- one for which I > have lots of questions, but no real answers. ... > So what he did was open up his address book and send his message to > everyone in it. And he's running one of these new e-mail clients that > happily caches addresses it sees in case you want them again. So all > of the addresses of people posting to the mailing lists he subscribed > to were in his address book cache, so when he grabbed his address > book, he grabbed all of those addresses, too. Yeah, I've seen this happen a couple times now. Typically it gets made into a public decapitation and all onlookers learn the DO NOT DO THAT lesson (or at least seem to). > So we have a clear violation of our anti-harvesting rules -- yet he > didn't overtly harvest. He just grabbed what was in his address book > at the time. Note: Many MUAs do this sort of address collection outside of Outlook. Heck, even the exmh I use can do collect addresses that way (and does by default IIRC) > This creates a major privacy quagmire. How do you set up rules for > something like that? You don't. You can't stop it technically so you have to rely on social engineering and a public pillory with frequent enough public humiliations that it starts entering the public unconscious. > Where does ownership and protection end? I draw the line at the edge of my MTA. Once you send a message to one my lists and it gets broadcast all rules and bets are off. I'll take reasonable care and due diligence within my server, but outside of that I don't attempt to control any more than I attempt to control the persistently rude (whom I normally unsubscribe, but that's another matter). > I just don't know how to deal with the issues this address caching > causes. I'm firmly of the mind that we can't. Its intrinsically an education issue. Now we can be effective in helping educate, but until is enters the social consciousness we'll be fighting up hill. > Ultimately, we're going to have to rethink our "no harvesting" rules, > and likely also write disclaimers explaining what our limits are. One possible technical approach is the mask all From: and CC: addresses on messages broadcast from a list with date limited plus addresses which reverse map on the list server back to the original address. Its no sort of permanent solution, it doesn't handle addresses quoted in .sigs, message bodies, or other odd/arbitrary headers, but it can do a whole lot to cripple address harvesting. Actually, I rather like this idea for certain lists. > We've actually considered switching our lists to obscured addresses, > turned that down as being worse than the disease (for now). You mean like the above? > But now we're wondering if we have to go to some sort of address > cloaking ON lists, maybe some kind of address remapping through the > server for replies, something. And I'm gritting my teeth at the > developers who created those @#$@$#@$#23 caches (which are nice in > some ways) for not also creating some way to flag addresses as not > cacheable. Because, IMHO, that'd solve this problem. Note that making a fixed and persistent address mapping really doesn't handle anything. You've just created another alias which works just as well for the SPAMmers or address harvesters and you can't (server side) distinguish between valid or SPAM mail sent to it any more successfully than you can for normal mail. Well, unless you setup TMDA-style filters for every such mapped plus address, which, asides from the cache expense really isn't such a bad idea. Hurm. I kinda like it actually. Date limiting the validity of the mapped address has two pleasant effects: It limits the size of your database of addresses, and it limits the window of opportunity for abuse of the address. > But they didn't. Grumble. Note that such address collection has been around a long time. exmh is by no means a particularly new or bleeding edge MUA and its had this sort of address collection feature for as long as I've used it. > I think it's an issue we have to come to grips with. I only see two addresses: 1) A pillory 2) Dynamic and/or filtered address mapping as above. Neither are particularly pleasant. Address mapping breaks as soon as Outlook (for instance) starts scanning message bodies for addresses to cache. > Are we hitting a point where mail list servers have to act as blind > front ends for all of the subscribers, where replies are processed by > those servers, and the server then takes on the job of acting as a > troll-exterminator and spam blocker? Yes, not yet, but soon. > And what does that really mean for things like Mailman? It means that Mailman will have to have a plug-in layer to do the appropriate processing. -- 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 claw@kanga.nu Wed Jul 17 05:39:54 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 16 Jul 2002 21:39:54 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: Message from John W Baxter of "Tue, 16 Jul 2002 12:19:16 PDT." References: Message-ID: <21585.1026880794@kanga.nu> On Tue, 16 Jul 2002 12:19:16 -0700 John W Baxter wrote: > I think the issue is larger than just mailing lists: SMTP-based email > will be unusable soon. The replacement will be something permission > based with electronic signatures involved, and some TMDA-like way to > get started conversing with someone. Note that TMDA handling is trivially automated by SPAMmers and that they will so automatically handle and bypass TMDA as soon as it becomes popular enough for them to notice. Heck, I'm using Mimefilter which mails back insulting messages (which mentioned the -owner address for the relevant list) to posters who send unwanted MIME parts. It took little time for the SPAM rate on -owner to increase by an order of magnitude. -- 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 claw@kanga.nu Wed Jul 17 05:43:43 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 16 Jul 2002 21:43:43 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: Message from Chuq Von Rospach of "Tue, 16 Jul 2002 12:58:05 PDT." References: Message-ID: <21629.1026881023@kanga.nu> On Tue, 16 Jul 2002 12:58:05 -0700 Chuq Von Rospach wrote: > On 7/16/02 12:19 PM, "John W Baxter" wrote: > Problem is, many users don't know how. And one could argue who ought > to solve this problem. True. > Should users be forced to jump through hoops to use a mail list > safely? Its worth noting that this problem is not unique to email or mailing lists. ICQ and other IM SPAM has been around a while. Heck, there have already been multiple attempts to SPAM Groove networks (which has a fairly strong structural protection against such). > Or is it the user's decision how safe to be? Minimally its a mutually complicit relationship. Each side has to assume some responsibility and behave in manners which assist the other in Doing The Right Thing (whatever that may be). The problem is, what is the base definition of Doing The Right Thing? > I could make a pithy comparison between spammers, computer viruses, > AIDS and safe sex, but you'd all throw veggies at me. I prefer eggs. >> I think the issue is larger than just mailing lists: SMTP-based email >> will be unusable soon. > No, but it has to adapt and evolve. Quickly. Yup. -- 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 jra@baylink.com Wed Jul 17 05:49:43 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 17 Jul 2002 00:49:43 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: ; from Chuq Von Rospach on Tue, Jul 16, 2002 at 08:11:43PM -0700 References: <20020716205740.62150@scfn.thpl.lib.fl.us> Message-ID: <20020717004943.05209@scfn.thpl.lib.fl.us> On Tue, Jul 16, 2002 at 08:11:43PM -0700, Chuq Von Rospach wrote: > On 7/16/02 5:57 PM, "Jay R. Ashworth" wrote: > >> But without rules, you can't teach the recipient what's right (with a cattle > >> prod, if necessary), and without rules, the lynch mob has no binding > >> authority. > > > > Where, by "rules", here, we mean "rules about what is acceptable mail"? > > Well, we're talking past each other a little bit, but at the same time, not. I'm so glad you've cleared that up, Chuq. ;-) > Because I think there's still a responsibility on the list admin, because > when someone signs up for a list, they're delegating some responsibility > over who can access their mailbox to the owner of the list, and the > agreement between the two are the rules set up about acceptable content. So > you can't duck some responsibility here. You can document your policies, and the person who wants to sign up can decide whether they can deal. > Oh, by the way, there's few ways guaranteed to PISS ME OFF more than someone > who signs up for a mailing list, and then starts bouncing selected pieces of > the mail because of filtering systems. Which usually happens because their > admin installs stupid filters... (I don't care if you throw them away, but I > hate showing up in the morning to 50 bounce messages because of some flakey > content filter...) That's why I never *bounce*. I either drop, or file. > Right now, for instance, one of the lists at apple is having a discussion > about coding problems. And the user starting it served up a code fragment > that included: > > int xxx = 0 > [...] > > You can imagine the chaos that ensues among the STUPID IS FILTER IDIOTS who > do overly simplistic filtering and assume it actually does something useful. :-) > But I'm not bitter. Naw. Not at all. > (and I'll be curious to see just how many bounces that I or barry see from > THAT simple notation.....) Yeah, RISKS gets this all the time. > > That sentence seems to assume that the majority of the people *falling > > in* the tarpits are people doing it by accident. I don't think that > > and I don't think *you* think that. > > Yes, I do. Since I (for the most part, most of the time) have the felons > locked out of the system pretty well, most of the people who cause problems > on my systems aren't trying to f--k with the system, they're people who are > oblivious, confused, or misguided. Even the spammer over the weekend meant > no harm, which doesn't mean harm wasn't caused. It was a classiv case of "my > cause is so important it justifies doing this" -- which, he found out the > hard way, a few hundred people disagreed with him over. Yeah. I keep forgetting that not everyone has spent 17 years on Usenet. But that brings us almost immediately around to "why use email to do a Usenet's job"... which *LOTS* of mailing lists are doing, frankly. In these days where the majority of newsreaders *do* understand multiple servers, that may no longer be warranted. > > By which I meant, "sigs of people in your address book." No, this > > doesn't solve the "stupid user" problem... but you don't *solve* that > > with technology. > > > > You solve it with a LART. > > Sometimes, the best solution is a public flogging, to teach everyone else to > be more careful next time. But if you overdo it, people tune you out, too. You've jumped ship before. So have I. They'll learn, eventually. > > Stipulated, but they're 80-90% of the market. I think even skewing for > > "non-Windoze users send more mail, you would still be about 70%, > > intuitively. > > We're working on that (a quiet voice whispers: "but a f---ing mac already! > It has unix inside for all you geeks, too!") > > Chasing people who directly harvest your listmanagement machine in > > person seems quite another. > > > > *That* you can't do on a case by case basis? Are you getting harvested > > every 5 minutes? > > You want to find out? Create a honeypot. Put some email addresses on it. > Attach it to your home page. See how quickly you start getting e-mail to > those addresses. > > You'll usually find the answer is "days". Once in a while, it's "hours". My sister runs a page that's always in the top 3 on Google in her keyword, on a user-named account on Mind-link. Been there over 6 years now. She's had a pseudo-bogus address in her POP3 domain buried in a mailto: on there for over a year. *One* piece of spam. She's not exactly a low profile target. You, OTOH, are. How well "hidden" were your honeypot machines? "plaidworks.com" is likely not a low-profile domain, neither. You put your honeypots in *Jellystone*, you get more bears... > > No, I mean in other cases. You're using webharvesting, it seems, as > > your major motivation here; it doesn't seem to me -- please don't take > > this wrong -- that there's evidence that it's really a big enough > > problem to solve (for people who don't send 40M pieces of email an > > hour). > > I don't think you're looking close enough. Run a few honeypot tests and see > how often people sneak a peek at YOUR system. On mine, it's a few days. Yaeh, but see above. Barry? You've been cowering in the corner there, letting us imitate Spenser and Hawk working up to it; comments? :-) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From claw@kanga.nu Wed Jul 17 05:50:48 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 16 Jul 2002 21:50:48 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: Message from barry@zope.com (Barry A. Warsaw) of "Tue, 16 Jul 2002 17:37:45 EDT." <15668.37417.657983.567997@anthem.wooz.org> References: <15668.37417.657983.567997@anthem.wooz.org> Message-ID: <22091.1026881448@kanga.nu> On Tue, 16 Jul 2002 17:37:45 -0400 Barry A Warsaw wrote: > We'd obviously have to get rid of the easy access to the raw mbox > file, so another question is whether that's still useful. > Occasionally it's damn handy if you're moving a list or gathering > statistics on it, but on the other hand, it's a rich source of > addresses to mine. I don't supply mboxes (or any other raw form of my archives). Providing mboxes or some other off-line form of the archives is the most common archive-related request I receive. > Also, what heuristic do you use to search for email addresses, and > what do you scrub them with? Do you want to attempt to obscure the > address (e.g. "barry--at--python--dot--org") or replace it altogether > (e.g. "[hidden email address]"), or maybe just replace it with a > truncation (e.g. "[localpart's email address]"). Long term I think dated addresses and/or TMDA-style filtering is the address. My main complaint against TMDA is that it doesn't email an alert message to me ala, "Bubba tried to email you and I'm holding his message pending confirmation." I'd like to know about held messages, or at least be able to trivially know so that I can pro-actively act to white-list and let mail thru without the other side having to jump thru rude hoops. > It kind of plays into Reply-To: munging doesn't it? If you won't be > able to reply to the original author, because we're anonymizing > messages, then you might as well munge Reply-To: to go back to the > list because that's the only posting address that makes sense. And > what if the original poster isn't a member of the list? Address mapping... > Or should Mailman get into the anonymous resender game? There's > probably a lot we could do here, but given the political risks of > anonymous resenders, do we even want go there? Date limited address maps. > Any chance you could make it down to DC for a side trip? We could > have a Mailman hacking sprint over a few dozen steamed Maryland blue > crabs and some cold ones. :) You might just drag me out to the other coast with offers like that. -- 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 jra@baylink.com Wed Jul 17 05:51:10 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 17 Jul 2002 00:51:10 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: ; from John W Baxter on Tue, Jul 16, 2002 at 09:25:44PM -0700 References: <15668.37417.657983.567997@anthem.wooz.org> <20020716204919.07257@scfn.thpl.lib.fl.us> Message-ID: <20020717005110.49677@scfn.thpl.lib.fl.us> On Tue, Jul 16, 2002 at 09:25:44PM -0700, John W Baxter wrote: > At 20:49 -0400 7/16/2002, Jay R. Ashworth wrote: > >But *why isn't this the recipients' problem*? > > Because the recipient gives up, and takes her ISP payments elsewhere, or > really gives up and takes them nowhere (which I'm tempted to do myself when > I retire). The final expansion of that is "The Internet is Disney World; everything is safe; nothing requires care." It ain't Afghanistan, either, but, really... Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From claw@kanga.nu Wed Jul 17 05:55:32 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 16 Jul 2002 21:55:32 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: Message from "Jay R. Ashworth" of "Tue, 16 Jul 2002 18:55:52 EDT." <20020716185552.54136@scfn.thpl.lib.fl.us> References: <20020716185552.54136@scfn.thpl.lib.fl.us> Message-ID: <22181.1026881732@kanga.nu> On Tue, 16 Jul 2002 18:55:52 -0400 Jay R Ashworth wrote: > On Tue, Jul 16, 2002 at 10:58:00AM -0700, Chuq Von Rospach wrote: > Automatically verifying PGP sigs as a whitelisting technique is merely > one approach that springs to mind. There are many more. Nothing prevents SPAMmers from creating endless addresses and GPG keys which they register with the various key servers, and they will once that barrier becomes popular enough to notice. > Yeah, but the Outhouse and OE teams aren't ever going there, and > they're your problem. No, they're merely the most visible manifestation. Address collection by MUAs is not new, and most of the other big Windows MUAs either do it as well, or can be relied upon adding that feature in the next 18 months. > Do you have documentary evidence, Chuq, that web harversters are the > *only* way that *a majority* of the spam-complainers addresses could > have gotten on those lists? Have you created test-accounts? Not 1 or > 2; a couple dozen, in different places? I've created a set of addresses on Kanga.Nu which pipe direct into razor-report. Those addresses are __ONLY__ visible on the relevant web pages. Each of them gets an average of 10 SPAM a day -- and those addresses are less than 6 months old. -- 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 claw@kanga.nu Wed Jul 17 06:06:47 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 16 Jul 2002 22:06:47 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: Message from Chuq Von Rospach of "Tue, 16 Jul 2002 17:07:48 PDT." References: Message-ID: <22393.1026882407@kanga.nu> On Tue, 16 Jul 2002 17:07:48 -0700 Chuq Von Rospach wrote: > On 7/16/02 2:37 PM, "Barry A. Warsaw" wrote: > One of the big things I dislike about Mhonarc is that archives are a > rather low-usage system, but maintaining the Mhonarc index pages is > rather intensive use of system resources. Rather. I've been messing with my current archive setup having the current PHP-based pages of variable assignments post-processed into SQL INSERT statements. A CGI then reads the SQL DB and builds the thread tree dynamically on display. It works fairly well. Not great, but it works. Handling the thread tree elegantly when In-Reply-To and References are bad is non-trivial. ObNote: cacheing the thread tree would be smart but is not that easy. -- 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 jwblist@olympus.net Wed Jul 17 06:08:35 2002 From: jwblist@olympus.net (John W Baxter) Date: Tue, 16 Jul 2002 22:08:35 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: References: Message-ID: At 17:28 -0700 7/16/2002, Chuq Von Rospach wrote: >On 7/16/02 5:35 PM, "Bob Puff@NLE" wrote: > >> I've seen the next generation of spammer software at work recently. >>Spammer's >> machine makes direct SMTP connection to my box > > >Actually, the REAL state of the art is that they look up your MX records, >and do this to the HIGHEST ranked one (not the lowest). This is on the (it >turns out, quite valid) assumption that it won't be spamblocked as well as >the main MX relay is, but will be validated to forward stuff in to you. And >where they're trying that, we're finding it works (grumble grr) damn well. > >Which means some of the assumptions we make on allowing, say, me on >plaidworks to generate email as chuq@apple.com and forward it to someone at >Apple are rapidly becoming obsolete, and how we design our backup MX systems >need to be looked at, also. The least-preferred MX ploy isn't terribly new. They don't even have to try the least-preferred first...just keep trying when rebuffed until one works (what...5xx means permanent?...hah). By the way, I saw a neighbor ISP shoot itself in the foot with a backup MX a couple of years ago (they reacted very quickly and very well when I called them, and fixed the problem, and now their mail goes to outsourced scanning before reaching them anyhow). They had their backup MX with a well known large provider and backbone (now part of a very well known very troubled organisation (spelling intentional)). And their backup MX got into one of the relay blocking lists. And it was an RBL they used (without exempting their own backup MX from checking). It took a bit of header reading to figure out why we sometimes couldn't send mail to them but the bounces weren't immediate. But only a bit. I don't think one can reasonably use a backup MX one doesn't control, these days (I suppose for Apple, that means Austin backs up Cupertino, and...). --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From claw@kanga.nu Wed Jul 17 06:09:08 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 16 Jul 2002 22:09:08 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: Message from Phil Barnett of "Tue, 16 Jul 2002 20:11:31 EDT." <200207162011.31975.philb@philb.us> References: <200207162011.31975.philb@philb.us> Message-ID: <22438.1026882548@kanga.nu> On Tue, 16 Jul 2002 20:11:31 -0400 Phil Barnett wrote: > On Tuesday 16 July 2002 13:58, Chuq Von Rospach wrote: It's a > thoughtful post, and includes many of the things I've been > contemplating myself, but I just had one thing to add about the list > management software becoming the arbiter of replies. >> Are we hitting a point where mail list servers have to act as blind >> front ends for all of the subscribers, where replies are processed by >> those servers, and the server then takes on the job of acting as a >> troll-exterminator and spam blocker? And what does that really mean >> for things like Mailman? > What would keep a spammer from using the reply mechanism to shuttle > replies back as if they were individual replies? Nothing. BUT, if the addresses are date limited the number of addresses in the valid pool is going to tend to be small (ie number of posters within the last window). This perforce forces SPAM harvesters to constant updating of their lists and a resultant huge rate of bad addresses. -- 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 claw@kanga.nu Wed Jul 17 06:12:29 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 16 Jul 2002 22:12:29 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: Message from Chuq Von Rospach of "Tue, 16 Jul 2002 17:21:17 PDT." References: Message-ID: <22505.1026882749@kanga.nu> On Tue, 16 Jul 2002 17:21:17 -0700 Chuq Von Rospach wrote: > On 7/16/02 3:55 PM, "Jay R. Ashworth" wrote: >> Outlaw Outlook? > Don't blame outlook here. Lots of mail clients do this 'temporary > caching'. $ wc -l ~/.exmh/exmh_addrs 289931 /home/claw/.exmh/exmh_addrs 'nuff said. -- 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 claw@kanga.nu Wed Jul 17 06:14:24 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 16 Jul 2002 22:14:24 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: Message from Chuq Von Rospach of "Tue, 16 Jul 2002 17:28:07 PDT." References: Message-ID: <22542.1026882864@kanga.nu> On Tue, 16 Jul 2002 17:28:07 -0700 Chuq Von Rospach wrote: > On 7/16/02 5:35 PM, "Bob Puff@NLE" wrote: >> I've seen the next generation of spammer software at work recently. >> Spammer's machine makes direct SMTP connection to my box > Actually, the REAL state of the art is that they look up your MX > records, and do this to the HIGHEST ranked one (not the lowest). Yup. I first started seeing this around March of last year and started mentioning that fact here and on the various list-manager lists at that time. > This is on the (it turns out, quite valid) assumption that it won't be > spamblocked as well as the main MX relay is, but will be validated to > forward stuff in to you. And where they're trying that, we're finding > it works (grumble grr) damn well. You're not alone. Currently some 30% of my SPAM comes thru backup MXes. -- 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 claw@kanga.nu Wed Jul 17 06:18:08 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 16 Jul 2002 22:18:08 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: Message from "Bob Puff@NLE" of "Tue, 16 Jul 2002 21:26:57 EDT." <3D34C7E1.FCDA98EB@nleaudio.com> References: <3D34C7E1.FCDA98EB@nleaudio.com> Message-ID: <22594.1026883088@kanga.nu> On Tue, 16 Jul 2002 21:26:57 -0400 bob > wrote: > Exactly. I didn't state that, but you put it well. But who cares if > it's the primary MX or not? If it hits any of my MXs, it will be > delivered. You can configure your MXes to require that HELO and From: must agree (at least within the same AS range), and to auto-reject/bounce messages that don't. -- 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@plaidworks.com Wed Jul 17 06:18:11 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 16 Jul 2002 22:18:11 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <21545.1026880612@kanga.nu> Message-ID: On 7/16/02 9:36 PM, "J C Lawrence" wrote: > You realise that subscribed robots on lists are going to be the next > SPAMmer trick? Of course they're easily defeated with an enforced > moderated first post, but 'net-wide that's going to be a painful > evolution. That's the least of my worries, actually. And people have been spamming yahoogroups for months with variations. And now they're spamming yahoogroups by uploading spam to the upload areas instead... My worry is other robots, but I'd rather not give anyone ideas in public. This hack is easily stopped. > Should work fairly well, especially for those cases where the > authentication data is not local. Which would, actually, allow a user to generate an authentication via a web site that stores into a MySQL database, allowing you to extend TMDA to use a clickurl instead of a reply token thingie. I wonder when the spambots will start scripting TMDA? It'd require bulletproof or temporary/disposable return addresses, but... Hmm. Can you predict TMDA's response for scripting? -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Very funny, Scotty. Now beam my clothes down here, will you? From claw@kanga.nu Wed Jul 17 06:20:20 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 16 Jul 2002 22:20:20 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: Message from barry@zope.com (Barry A. Warsaw) of "Tue, 16 Jul 2002 21:34:16 EDT." <15668.51608.174634.163001@anthem.wooz.org> References: <15668.37417.657983.567997@anthem.wooz.org> <15668.51608.174634.163001@anthem.wooz.org> Message-ID: <22644.1026883220@kanga.nu> On Tue, 16 Jul 2002 21:34:16 -0400 Barry A Warsaw wrote: > Hmm, maybe you're right. You've got to keep those random forwarding > addresses alive for a long (configurable) time so that replies will > continue to work. Really? How about a dated address which works transparently for a week then reverts to a TMDA-like filter for another fortnight, and then dies? -- 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 jwblist@olympus.net Wed Jul 17 06:21:38 2002 From: jwblist@olympus.net (John W Baxter) Date: Tue, 16 Jul 2002 22:21:38 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <3D34BBC9.C0D8CB76@nleaudio.com> References: <15668.37914.173241.870536@anthem.wooz.org> <3D34BBC9.C0D8CB76@nleaudio.com> Message-ID: "Bob Puff@NLE" >Not to get too far OT here but... > >I've seen the next generation of spammer software at work recently. >Spammer's machine makes direct SMTP connection to my box, gives MY address >as the FROM:, TO:, and >REPLY-TO:. This bypasses all the open relay testing, and would only leave >stuff like SA to detect it. Actually, you missed "version a" of this, in which a user is picked, and messages are sent to 8 [about] or fewer alphabetically-near addresses on the same domain. I *think* the "or fewer" mostly came from stale addresses being bounced. So this thing was really clever, right? Not really...there was a supposed Received: header "below" the Subject: header. With a made up host name in the supposedly sending domain, and SMTP not esmtp protocol. Not hard to catch and freeze by parsing headers, although I froze based on another header instead. (The latter turned out not to be specific to the spam in question [just because it wasn't found in any of the message I have in my last couple of years of history didn't make it unusual, just old, as it turned out]. It recently caught another juicy spammer who was easy to deal with but whom I wouldn't have noticed if I hadn't had to vette the frozen messages.) Plan B of this series* is the xxx@example.com to xxx@example.com form you're seeing...which sometimes is, it turns out xxx@example.com to yyy@example.com. This form lacks the misplaced phony Received: header. *I see it as part of the series...the perps may not. --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA mailman-developers...where no canned worm is safe. From claw@kanga.nu Wed Jul 17 06:31:43 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 16 Jul 2002 22:31:43 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: Message from Chuq Von Rospach of "Tue, 16 Jul 2002 22:18:11 PDT." References: Message-ID: <22785.1026883903@kanga.nu> On Tue, 16 Jul 2002 22:18:11 -0700 Chuq Von Rospach wrote: > On 7/16/02 9:36 PM, "J C Lawrence" wrote: >> Should work fairly well, especially for those cases where the >> authentication data is not local. > Which would, actually, allow a user to generate an authentication via > a web site that stores into a MySQL database, allowing you to extend > TMDA to use a clickurl instead of a reply token thingie. Damned good idea. > I wonder when the spambots will start scripting TMDA? Once it hits a thousandth of a percentage point. > It'd require bulletproof or temporary/disposable return addresses, > but... An easy hack. > Hmmm. Can you predict TMDA's response for scripting? Yes, currently there is precious little entropy insertion. The more simple problem (and easy to fix) is that TMDA and like systems rely on plus addressing and the base form of the address continues to deliver directly... -- 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@plaidworks.com Wed Jul 17 06:33:20 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 16 Jul 2002 22:33:20 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <20020717002253.14548@scfn.thpl.lib.fl.us> Message-ID: On 7/16/02 9:22 PM, "Jay R. Ashworth" wrote: >> says some variation of "you are a dead man". Three weeks later, the other >> guy's house burns down because of arson, and all you have is an archive with >> no identifying information in it.... > > Well, ok... but in a case like that, your mailer logs would likely have > the appropriate information. But still, as rare as such a circumstance > is, I don't see that you have any moral obligation to be *that* prepared. How many people keep their logs three weeks? How many people long ago stopped keeping detailed SMTP logs because of their size? And rare as the circumstance is, if YOUR house was burned down, would you still care that it was rare? (it's real easy to say "don't care, it's someone else's house...") > Stipulated. But I don't believe that the toaster *is* cheap and shoddy > -- ie: that it's *your* responsibility -- merely because people break > into your house, and jam oversized bagels into your toaster repeatedly > until it won't hold toast anymore. Take a look at the court system. You're so far in the minority it's not funny (really not funny). Have you ever read the instruction manual for a toaster? The warning pages in the instruction manual, that say things like "do not use toaster in shower"? Because fi they DON'T say that, they get sued because someone does? > Except that the spam isn't the *problem*. The *spammers* are. Sorry. That's like saying "bullets aren't a problem, guns are". If you get shot, you don't waste time arguing semantics like this. Unless, I guess, you're a libertarian. But frankly, most of the libertarians I know who HAVE been shot (instead of arguing about what they'd do if, theoretically, they were shot) stop arguing semantics, too. > Even when they get unreasonably strident, and scream for all the wrong > reasons -- and they so -- I still back the Second Amendment > absolutists, because history has proven that they *put that amendment > in there for a reason*. That would be a fun argument, but I'll spare the list. Pass. (but if you look at the historical record of the debates over the amendment, it's a lot more ambiguous what the founding fathers THOUGHT, vs. how it's been interpreted. But, pass...) > It is largely because of RMS' intransigience on many points related to > Free Software that we have most of it, and most particularly Linux -- > I really don't believe it would have happened at all except for the > developer-protection provided by the GPL. And off we go into left field, to blame something completely tangential to the issue at hand. Oh, never mind, pass. > Sometimes a cigar *is* just a cigar. That's what monica said, too. > Sometimes, you've got to let junior take the fall. Why? How very libertarian of you. May you never find someone calling you junior... (it's easy to say "let them eat cake" when you aren't starving with them. At least until the wagon arrives....) > Not at all. It's not a question of ease. Undertaking responsibility > is not easy. No, ducking responsibility is easy. Undertaking responsbility, however, is how things get done. > Someone has to fix the problem. It has been proven to my satisfaction > that the technologists can't: it's not a technology-fix problem (so few > 'problems' are). Someone has to get *pissed*. > > That'd be the people with the mailboxes, Bob. Wrong. It's the people with the skillset. Lots of people have mailboxes. Few people have the skillsets. But those people, it seems, are willing to let others rot, because it's easier for them personally. Well, some of them. Look, if I wanted easy, I wouldn't even be on this list. I'd just download tarballs and do what I felt like. I'd like to think we're all on this list because we're better than that. > Fine. > > But this isn't procmail, nor SpamAssassin; they're at the other end of > the hall; third and fifth doors on the right, respectively. > > This is a mailing list program. This is a tool that users attach trust to, and that trust is that we won't abuse their mailbox and will send them what we tell them we'll send them. If they stop trusting the tool, they'll stop using it. So we have a responsibility (if not to those users, to the TOOL) to do what we can to protect that trust a user attaches to the program when they agree to subscribe to a mail list through it. > Letting spam through likely only gets you yelled at; accidentally > blocking important stuff gets you burned. No, actually, both get you yelled at and/or burned, depending on who gets upset about what. At some level, it's a no-win situation.... -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Yes, I am an agent of Satan, but my duties are largely ceremonial. From chuqui@plaidworks.com Wed Jul 17 06:34:51 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 16 Jul 2002 22:34:51 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <22644.1026883220@kanga.nu> Message-ID: >> Hmm, maybe you're right. You've got to keep those random forwarding >> addresses alive for a long (configurable) time so that replies will >> continue to work. > > Really? > > How about a dated address which works transparently for a week then > reverts to a TMDA-like filter for another fortnight, and then dies? What happens when someone sees an address in the archive six months from now and needs to contact that author? -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Yes, I am an agent of Satan, but my duties are largely ceremonial. From chuqui@plaidworks.com Wed Jul 17 06:35:50 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 16 Jul 2002 22:35:50 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <22785.1026883903@kanga.nu> Message-ID: On 7/16/02 10:31 PM, "J C Lawrence" wrote: >> Hmmm. Can you predict TMDA's response for scripting? > > Yes, currently there is precious little entropy insertion. (insert filthy expletive involving sheep and the second amendment) -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Stress is when you wake up screaming and you realize you haven't fallen asleep yet. From claw@kanga.nu Wed Jul 17 06:36:54 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 16 Jul 2002 22:36:54 -0700 Subject: [Mailman-Developers] Re: multiple addresses in (was AOL and odd) Reply-to (fwd) Message-ID: <22891.1026884214@kanga.nu> Nick Simicich asserts that AOL will silently discard mail which lists multiple addresses in Reply-To:, one of which matches From: and is an AOL address. Later in that thread: ------- Forwarded Message From: "David W. Tamkin" To: "list-managers" Subject: Re: multiple addresses in (was AOL and odd) Reply-to Date: Tue, 16 Jul 2002 20:01:35 -0500 Nick gave the example, | > Reply-to: listname@listdomain, posting-user@example.com JCL commented, | Having [mutiple addresses in] Reply-To is a Good ... and Damned Useful [Thing]. It seems to me, though, that the list membership would be better served with this form: Reply-To: postauthor@its.domain, listname@listserver.domain because the MUAs with which I'm familiar make it anywhere from slightly easier to far easier for the respondent to remove addresses from the right of the reply's To: than from the left. ------- End of Forwarded Message -- 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@plaidworks.com Wed Jul 17 06:44:41 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 16 Jul 2002 22:44:41 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <20020717004943.05209@scfn.thpl.lib.fl.us> Message-ID: On 7/16/02 9:49 PM, "Jay R. Ashworth" wrote: > You can document your policies, and the person who wants to sign up can > decide whether they can deal. I don't think that's always good enough. You have to do what you can to back the policies up. Unless, of course, your policy is "you're screwed if you post to my list, and good luck stopping the spammers". Which is, effectively, what "make the owner of the mailbox handle it" does as a policy. Although I doubt you'd phrase it quite that way... >> But I'm not bitter. > > Naw. Not at all. What has me pissed off is that I thought we did a pretty good job of fixing the weaknesses of Mailman in 2.1, and figured maybe we'd have some time to sit back and think through some really nice conceptual breakthrough type stuff. And now, we're slogging in the trenches again looking for ways to keep the bullets out of the latrine long enough to get anything accomplished.... Heh. Wanna guarantee messages get bounced all over the place? Just use the "V" word in an email. You know which one I mean. You'll set off alarms all over the universe. It's more fun than running through a parking lot seeing which cars have movement detectors on the alarms. Not that, um, I do that, you know. > Yeah. I keep forgetting that not everyone has spent 17 years on > Usenet. Newbie. > But that brings us almost immediately around to "why use email to do a > Usenet's job"... which *LOTS* of mailing lists are doing, frankly. Because usenet is so broke none of us even think of fixing it any more? I love to say "if all you have his a hammer, everything is a nail". In this case, email is our hammer, and mail lists aren't always appropriate for hammering, but have you seen what those idiots did to our screwdriver? I ain't picking that up, not without tongs and a blowtorch. >> Sometimes, the best solution is a public flogging, to teach everyone else to >> be more careful next time. But if you overdo it, people tune you out, too. > > You've jumped ship before. So have I. Hell, I turned jumping ship into an art form. In my heyday, usenet people set their clocks by it. Well, maybe their calendars. I finally grew up, too, and learned to both manage my stress levels and accept my responsibilities. > They'll learn, eventually. Not that I've noticed. >> We're working on that (a quiet voice whispers: "but a f---ing mac already! >> It has unix inside for all you geeks, too!") > > Heh. A unix box with a pretty damn good gui, in a lap top so you can carry it anywhere, for about a grand. Effing wow. Oh, never mind..... (giggle) > My sister runs a page that's always in the top 3 on Google in her > keyword, on a user-named account on Mind-link. Been there over 6 years > now. She's had a pseudo-bogus address in her POP3 domain buried in a > mailto: on there for over a year. > > *One* piece of spam. I am amazed. > She's not exactly a low profile target. > > You, OTOH, are. How well "hidden" were your honeypot machines? > "plaidworks.com" is likely not a low-profile domain, neither. You flatter me. I think. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after From chuqui@plaidworks.com Wed Jul 17 06:45:59 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 16 Jul 2002 22:45:59 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <20020717005110.49677@scfn.thpl.lib.fl.us> Message-ID: >>> But *why isn't this the recipients' problem*? >> >> Because the recipient gives up, and takes her ISP payments elsewhere, or >> really gives up and takes them nowhere (which I'm tempted to do myself when >> I retire). > > The final expansion of that is "The Internet is Disney World; > everything is safe; nothing requires care." Disagree. The final expansion of that is "the internet is the shopping mall. You shouldn't have to worry about drive by shootings, but you may run into the occcasional pickpocket..." (actually, pickpockets can be a significant problem in disney parks, but I didn't say that....) -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Very funny, Scotty. Now beam my clothes down here, will you? From chuqui@plaidworks.com Wed Jul 17 06:47:13 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 16 Jul 2002 22:47:13 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <22393.1026882407@kanga.nu> Message-ID: On 7/16/02 10:06 PM, "J C Lawrence" wrote: > ObNote: cacheing the thread tree would be smart but is not that easy. On the other hand, if your storage system allows, sorting by subject line by posted date simulates most of that. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ No! No! Dead girl, OFF the table! -- Shrek From claw@kanga.nu Wed Jul 17 06:47:55 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 16 Jul 2002 22:47:55 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: Message from Chuq Von Rospach of "Tue, 16 Jul 2002 22:34:51 PDT." References: Message-ID: <23022.1026884875@kanga.nu> On Tue, 16 Jul 2002 22:34:51 -0700 Chuq Von Rospach wrote: >> How about a dated address which works transparently for a week then >> reverts to a TMDA-like filter for another fortnight, and then dies? > What happens when someone sees an address in the archive six months > from now and needs to contact that author? Is that really a valid and interesting case that can't be (usually) handled by posting directly to the list? Heck, have a CGI on your archives that allows writing replies back to the list and/or original poster... Yeah, I know, arms race, but at least this is a trivially changed/editable/confoundable system to make difficult to automate. -- 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 claw@kanga.nu Wed Jul 17 06:49:10 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 16 Jul 2002 22:49:10 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: Message from Chuq Von Rospach of "Tue, 16 Jul 2002 22:35:50 PDT." References: Message-ID: <23057.1026884950@kanga.nu> On Tue, 16 Jul 2002 22:35:50 -0700 Chuq Von Rospach wrote: > On 7/16/02 10:31 PM, "J C Lawrence" wrote: >>> Hmmm. Can you predict TMDA's response for scripting? >> Yes, currently there is precious little entropy insertion. > (insert filthy expletive involving sheep and the second amendment) Ahem. Yeah, but. TMDA not only gets most of the way there, it also builds and provides most of the framework needed to get there. That's not a small thing, and shouldn't be an ignored thing. -- 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@plaidworks.com Wed Jul 17 06:50:25 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 16 Jul 2002 22:50:25 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <23022.1026884875@kanga.nu> Message-ID: >> What happens when someone sees an address in the archive six months >> from now and needs to contact that author? > > Is that really a valid and interesting case that can't be (usually) > handled by posting directly to the list? No, but it's something that happens often enough that I have to worry about it, and not often enough that I consider it a showstopper. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ The first rule of holes: If you are in one, stop digging. From chuqui@plaidworks.com Wed Jul 17 06:57:44 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 16 Jul 2002 22:57:44 -0700 Subject: [Mailman-Developers] Re: multiple addresses in (was AOL and odd) Reply-to In-Reply-To: <22891.1026884214@kanga.nu> Message-ID: On 7/16/02 10:36 PM, "J C Lawrence" wrote: > > Nick Simicich asserts that AOL will silently > discard mail which lists multiple addresses in Reply-To:, one of which > matches From: and is an AOL address. Later in that thread: AOL silently blackholes stuff that trips its spam filters. I can easily see, given the recent spate of spam with forged headers to look like it's coming FROM someone (or you) @ your domain to someone (or you) @ your domain, that comes from off-site, that AOL has decided that anything that looks to be from an AOL account but coming from outside the AOL universe is probably spam. Because, probably, it is. It's basically hit a point where it's unsafe to accept mail "from" your domain unless it's explicitly coming from a trusted SMTP source. And yes, that screws over someone (like me) who owns a domain on a box somewhere, and who goes on the road and uses a dialup like earthlink and wants to continue using his real domain in his email. But the spammers are now exploiting that, so you're going to see everyone lock it down tight, both on the receiving side, and (with responsible ISPs) the sending side (by limiting what domain names they'll propogate outward) -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ IMHO: Jargon. Acronym for In My Humble Opinion. Used to flag as an opinion something that is clearly from context an opinion to everyone except the mentally dense. Opinions flagged by IMHO are actually rarely humble. IMHO. (source: third unabridged dictionary of chuqui-isms). From claw@kanga.nu Wed Jul 17 06:59:17 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 16 Jul 2002 22:59:17 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: Message from Chuq Von Rospach of "Tue, 16 Jul 2002 22:50:25 PDT." References: Message-ID: <23285.1026885557@kanga.nu> On Tue, 16 Jul 2002 22:50:25 -0700 Chuq Von Rospach wrote: >>> What happens when someone sees an address in the archive six months >>> from now and needs to contact that author? >> Is that really a valid and interesting case that can't be (usually) >> handled by posting directly to the list? > No, but it's something that happens often enough that I have to worry > about it, and not often enough that I consider it a showstopper. Different loads. How about the CGI business as a solution? You can do that without exposing the address and while doing due diligence on constraining abuse. ObNote: Apple runs a large enough mail ship that its an attractive target in and of itself should you do an automated system like this. *THAT* is painful as you can't insert enough entropy into the UI behavior without becoming either mappable or unusable -- which basically means you end up doing something like a TMDA filter which holds the message for the final recipient for a week or so...which makes havoc of your storage and bandwidth budgets... -- 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 claw@kanga.nu Wed Jul 17 07:03:02 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 16 Jul 2002 23:03:02 -0700 Subject: [Mailman-Developers] Re: multiple addresses in (was AOL and odd) Reply-to In-Reply-To: Message from Chuq Von Rospach of "Tue, 16 Jul 2002 22:57:44 PDT." References: Message-ID: <23375.1026885782@kanga.nu> On Tue, 16 Jul 2002 22:57:44 -0700 Chuq Von Rospach wrote: > On 7/16/02 10:36 PM, "J C Lawrence" wrote: >> Nick Simicich asserts that AOL will silently >> discard mail which lists multiple addresses in Reply-To:, one of >> which matches From: and is an AOL address. Later in that thread: > AOL silently blackholes stuff that trips its spam filters. > I can easily see, given the recent spate of spam with forged headers > to look like it's coming FROM someone (or you) @ your domain to > someone (or you) @ your domain, that comes from off-site, that AOL has > decided that anything that looks to be from an AOL account but coming > from outside the AOL universe is probably spam. Because, probably, it > is. If, as has been suggested, AOL users can't normally set Reply-To:, such a check on Reply-To is also quite valid (or damned close enough for AOL's uses). > It's basically hit a point where it's unsafe to accept mail "from" > your domain unless it's explicitly coming from a trusted SMTP > source. And yes, that screws over someone (like me) who owns a domain > on a box somewhere, and who goes on the road and uses a dialup like > earthlink and wants to continue using his real domain in his > email. Do *NOT* talk to me about POP before SMTP. I repeat, DO NOT... > But the spammers are now exploiting that, so you're going to see > everyone lock it down tight, both on the receiving side, and (with > responsible ISPs) the sending side (by limiting what domain names > they'll propogate outward) Bingo. I've already started seeing this. -- 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@plaidworks.com Wed Jul 17 07:15:24 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 16 Jul 2002 23:15:24 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <23285.1026885557@kanga.nu> Message-ID: On 7/16/02 10:59 PM, "J C Lawrence" wrote: > How about the CGI business as a solution? You can do that without > exposing the address and while doing due diligence on constraining > abuse. Once you build the infrastructure to support cloaked-but-forwarding addresses, it's definitely possible. But not 1st generation stuff, I don't think. > ObNote: Apple runs a large enough mail ship that its an attractive > target in and of itself should you do an automated system like this. Shh. If you don't tell anyone... (oh, wait, security through obscurity is a bad idea...) -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Very funny, Scotty. Now beam my clothes down here, will you? From claw@kanga.nu Wed Jul 17 07:21:57 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 16 Jul 2002 23:21:57 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: Message from Chuq Von Rospach of "Tue, 16 Jul 2002 23:15:24 PDT." References: Message-ID: <23678.1026886917@kanga.nu> On Tue, 16 Jul 2002 23:15:24 -0700 Chuq Von Rospach wrote: > On 7/16/02 10:59 PM, "J C Lawrence" wrote: >> How about the CGI business as a solution? You can do that without >> exposing the address and while doing due diligence on constraining >> abuse. > Once you build the infrastructure to support cloaked-but-forwarding > addresses, it's definitely possible. But not 1st generation stuff, I > don't think. True. Its a pretty clean v2 tho, and with a short runway between v1 and v2. >> ObNote: Apple runs a large enough mail ship that its an attractive >> target in and of itself should you do an automated system like this. > Shh. If you don't tell anyone... (oh, wait, security through obscurity > is a bad idea...) There are many problems which become clearly non-linear purely due to the Big Number effect. SPAM is one of those problems on all three ends of the equation. -- 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 barry@zope.com Wed Jul 17 07:39:16 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 17 Jul 2002 02:39:16 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... References: <20020716204919.07257@scfn.thpl.lib.fl.us> Message-ID: <15669.4372.352349.350097@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> 1) I (as the list admin to the recipient) am offering a CVR> service. I strongly believe that if I'm offering a service, I CVR> have an ethical (if not legal) responsibility to make that CVR> service as problem free as possible. Wow, I guess you don't read many EULAs do ya? :) your-problem-son-is-ya-got-morals-ly y'rs, -Barry P.S. Someday soon you/we may indeed have that legal responsibility. Although obviously a worthy goal, I'm actually a little fearful of what that'll mean for free software. From chuqui@plaidworks.com Wed Jul 17 07:46:12 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 16 Jul 2002 23:46:12 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <15669.4372.352349.350097@anthem.wooz.org> Message-ID: On 7/16/02 11:39 PM, "Barry A. Warsaw" wrote: > Wow, I guess you don't read many EULAs do ya? :) > > your-problem-son-is-ya-got-morals-ly y'rs, I can sleep at night, too. But then, I believe in doing what I think is right, not what I can get away with as legal. If that bothers you, sue me... (heh) > P.S. Someday soon you/we may indeed have that legal responsibility. > Although obviously a worthy goal, I'm actually a little fearful of > what that'll mean for free software. Sorry, I just don't think they'l suceed at nuking free software. Too much big business depends on it now. Vigilance is good, but when push comes to shove, the ones that are trying to screw it up won't succeed. Besides, fi the US outlaws it, like, oh, stem cell research, it'll just slide overseas out of the US jurisdiction, and the US will find that over time, it'll be ata competitive disadvantage because of it... -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ The first rule of holes: If you are in one, stop digging. From barry@zope.com Wed Jul 17 07:49:48 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 17 Jul 2002 02:49:48 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... References: <20020716205740.62150@scfn.thpl.lib.fl.us> Message-ID: <15669.5004.773991.773474@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> Oh, by the way, there's few ways guaranteed to PISS ME OFF CVR> more than someone who signs up for a mailing list, and then CVR> starts bouncing selected pieces of the mail because of CVR> filtering systems. Which usually happens because their admin CVR> installs stupid filters... (I don't care if you throw them CVR> away, but I hate showing up in the morning to 50 bounce CVR> messages because of some flakey content filter...) Bouncing them to the actual errors address is one thing, but bouncing them to the author of the email is the worst offense. OTOH, I have no problem with Mailman being aggressive in disabling such offenders. CVR> Right now, for instance, one of the lists at apple is having CVR> a discussion about coding problems. And the user starting it CVR> served up a code fragment that included: | int xxx = 0 | [...] CVR> You can imagine the chaos that ensues among the STUPID IS CVR> FILTER IDIOTS who do overly simplistic filtering and assume CVR> it actually does something useful. CVR> But I'm not bitter. CVR> (and I'll be curious to see just how many bounces that I or CVR> barry see from THAT simple notation.....) I'm actually quite surprised that we don't see more of those, especially on the python-checkins list, given Guido's prediliction for comment markers (uppercase tres-equis). OTOH, I seem to remember our Windows dude got a lot of those shunted off into his spam folder before he taught it to ignore those. >> Stipulated, but they're 80-90% of the market. I think even >> skewing for "non-Windoze users send more mail, you would still >> be about 70%, intuitively. CVR> We're working on that (a quiet voice whispers: "but a f---ing CVR> mac already! It has unix inside for all you geeks, too!") OT: Chuq will be so proud of me. I'm Windows free (tm) and my two Linux boxes sit right next to my two G4 towers. OSX rules and if Cubase ever /finally/ releases SX for MacOSX I won't go back (yes, I know Apple just bought Emagic -- two weeks after I flipped a coin and took the plunge off the other side. ;). -Barry From satyap@satya.virtualave.net Wed Jul 17 07:56:16 2002 From: satyap@satya.virtualave.net (Satya) Date: Tue, 16 Jul 2002 23:56:16 -0700 (PDT) Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: Message-ID: On Jul 16, 2002 at 22:44, Chuq Von Rospach wrote: >On 7/16/02 9:49 PM, "Jay R. Ashworth" wrote: >the policies up. Unless, of course, your policy is "you're screwed if you >post to my list, and good luck stopping the spammers". Which is, >effectively, what "make the owner of the mailbox handle it" does as a >policy. Although I doubt you'd phrase it quite that way... I wouldn't, but that would be my policy, yes. OTOH, no one pays me to run mailing lists. Again, it's the same thing: have the mechanism (I'm not even sure *which* mechanism(s) you're talking about now), let $foo decide the policy, where $foo iterates over the list of users. Of course, that causes one person's miscalculation to be another person's (times n) headache. Networks are like that. >>> But I'm not bitter. >> Naw. Not at all. I see no "bitter" here. >Heh. Wanna guarantee messages get bounced all over the place? Just use the >"V" word in an email. You know which one I mean. You'll set off alarms all "virus"? Something else? VD? What? >over the universe. It's more fun than running through a parking lot seeing Oooh, cool! >I love to say "if all you have his a hammer, everything is a nail". In this >case, email is our hammer, and mail lists aren't always appropriate for >hammering, but have you seen what those idiots did to our screwdriver? I >ain't picking that up, not without tongs and a blowtorch. But now they want to borrow the hammer, too. (Insert Picard's speech about drawing the line here.) >> My sister runs a page that's always in the top 3 on Google in her >> *One* piece of spam. >I am amazed. So am I. I mean, *one*? -- Satya. Could you continue your petty bickering ? I find it most intriguing. From chuqui@plaidworks.com Wed Jul 17 07:55:25 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 16 Jul 2002 23:55:25 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <15669.5004.773991.773474@anthem.wooz.org> Message-ID: On 7/16/02 11:49 PM, "Barry A. Warsaw" wrote: > CVR> starts bouncing selected pieces of the mail because of > CVR> filtering systems. Which usually happens because their admin > CVR> installs stupid filters... > > Bouncing them to the actual errors address is one thing, but bouncing > them to the author of the email is the worst offense. OTOH, I have no > problem with Mailman being aggressive in disabling such offenders. For the most part, they seem to end up going to the -admin address. And when the admin gets tired of throwing them away, we tell them to send a message to the subscribers saying "get your filters fixed or we'll remove you". Mostly, they end up getting unsubscribed, since the filters are usually under control of IS people who are too busy saving the universe to realize they're impacting company business with false positives... -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after From chuqui@plaidworks.com Wed Jul 17 08:02:02 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 17 Jul 2002 00:02:02 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: Message-ID: On 7/16/02 11:56 PM, "Satya" wrote: >> Heh. Wanna guarantee messages get bounced all over the place? Just use the >> "V" word in an email. You know which one I mean. You'll set off alarms all > > "virus"? Something else? VD? What? Rhymes with "niagara" as in the falls. >>> My sister runs a page that's always in the top 3 on Google in her >>> *One* piece of spam. >> I am amazed. > > So am I. I mean, *one*? Must have been a mistake. Usually, once you get one, you need to pull out the waders. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ He doesn't have ulcers, but he's a carrier. From barry@zope.com Wed Jul 17 08:09:28 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 17 Jul 2002 03:09:28 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... References: <20020716204919.07257@scfn.thpl.lib.fl.us> <20020717002253.14548@scfn.thpl.lib.fl.us> Message-ID: <15669.6184.241555.954040@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> Mutt's highlighting regexes are pretty decent, but I don't JRA> know that *any* RE can match both quoted and non-quoted JRA> mailbox names reliably. You have to invoke the 80/20 rule or you'll either go insane, or duplicate mail-extr.el's syntax driven state machine in your programming language of choice. JRA> There's an argument going on somewhere else right now -- I JRA> thought it was bugtraq, but I seem to have misplaced the JRA> message -- about whether email addresses can have an RHS that JRA> terminates in a . JRA> The poster says no way, I say that 2821 and 1034/5 say yes. I'm not sure. 2822 would be the definitive RFC wouldn't it? -------------------- snip snip -------------------- addr-spec = local-part "@" domain local-part = dot-atom / quoted-string / obs-local-part dot-atom = [CFWS] dot-atom-text [CFWS] dot-atom-text = 1*atext *("." 1*atext) atext = ALPHA / DIGIT / ; Any character except controls, "!" / "#" / ; SP, and specials. "$" / "%" / ; Used for atoms "&" / "'" / "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / obs-local-part = word *("." word) word = atom / quoted-string atom = [CFWS] 1*atext [CFWS] -------------------- snip snip -------------------- It would seem that the local-part can't end in a `.'. JRA> Someone has to fix the problem. It has been proven to my JRA> satisfaction that the technologists can't: it's not a JRA> technology-fix problem (so few 'problems' are). Someone has JRA> to get *pissed*. In a different context, the same question: do you think the corporate fraud reforms now being debated in congress will solve the problem? People /are/ pissed and are demanding both technological and non-technological fixes. But maybe it's just 3am and I'm starting to hallucinate. ;) > I can't give any definite examples to protect the people involved, but I > know of a couple of people who've had their careers significantly impacted > because of this stuff. Maybe not fatal, but third degree burns. JRA> The topic being false-positive-ly blocked "spam", aren't JRA> those evidence for the prosecution, not the defense? False positives don't scare me, but that's because we've got at least 5 volunteer postmasters screening the reports and rescuing probably 1 message a week, if that. What happens when the true-positives start making a stink because they demand that their spam get through? JRA> Letting spam through likely only gets you yelled at; JRA> accidentally blocking important stuff gets you burned. JRA> We are on the critical path, folks. I know you know that, JRA> but the explicit reminder isn't going to get me fired. JRA> Fail-safe isn't just for aerospace anymore. In a way I agree, but by the same token, email is such a flakey system throughout that I think people have fairly low expectations that a message they send will get delivered, read, and answered. If you positively must get an answer to a question and in a hurry, email's a lousy way to ensure that. -Barry From barry@zope.com Wed Jul 17 08:17:11 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 17 Jul 2002 03:17:11 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... References: <21545.1026880612@kanga.nu> Message-ID: <15669.6647.119072.773566@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: JCL> Note: Many MUAs do this sort of address collection outside of JCL> Outlook. Heck, even the exmh I use can do collect addresses JCL> that way (and does by default IIRC) I've got 40k+ entries in my bbdb database, give or take duplicates, 'bots, and multiple emails for the same person. JCL> One possible technical approach is the mask all From: and CC: JCL> addresses on messages broadcast from a list with date limited JCL> plus addresses which reverse map on the list server back to JCL> the original address. Its no sort of permanent solution, it JCL> doesn't handle addresses quoted in .sigs, message bodies, or JCL> other odd/arbitrary headers, but it can do a whole lot to JCL> cripple address harvesting. JCL> JCL> Actually, I rather like this idea for certain lists. Indeed. And as you point out, date limiting is the trick. Then again, once the alias is expired, posting to the list is your only option, and then you're back to reply-to munging. -Barry From barry@zope.com Wed Jul 17 08:21:15 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 17 Jul 2002 03:21:15 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... References: <20020716205740.62150@scfn.thpl.lib.fl.us> <20020717004943.05209@scfn.thpl.lib.fl.us> Message-ID: <15669.6891.666046.300064@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> Barry? You've been cowering in the corner there, letting us JRA> imitate Spenser and Hawk working up to it; comments? :-) What's my budget and where's my staff? :) -Barry From satyap@satya.virtualave.net Wed Jul 17 08:27:36 2002 From: satyap@satya.virtualave.net (Satya) Date: Wed, 17 Jul 2002 00:27:36 -0700 (PDT) Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: Message-ID: On Jul 17, 2002 at 00:02, Chuq Von Rospach wrote: >On 7/16/02 11:56 PM, "Satya" wrote: >> "virus"? Something else? VD? What? > >Rhymes with "niagara" as in the falls. Ah, Viagra. Oops. Yes, I'm baiting. -- Satya. But I thought you did the backups! From barry@zope.com Wed Jul 17 08:28:31 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 17 Jul 2002 03:28:31 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... References: <15668.37417.657983.567997@anthem.wooz.org> <22091.1026881448@kanga.nu> Message-ID: <15669.7327.733812.68665@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: JCL> I don't supply mboxes (or any other raw form of my archives). JCL> Providing mboxes or some other off-line form of the archives JCL> is the most common archive-related request I receive. I'd like to better understand the motivation for those requests. In my cases I think it's because Pipermail archives don't give you two important things: posting replies via the web, and the ability to forward archive messages to an email address. >> Any chance you could make it down to DC for a side trip? We >> could have a Mailman hacking sprint over a few dozen steamed >> Maryland blue crabs and some cold ones. :) JCL> You might just drag me out to the other coast with offers JCL> like that. August and September are prime crab-pickin' months y'know, and even though they're expensive this year, I'm not adversed to a quick morning hop down to the Eastern Shore for a bushel of jumbos. :) paper-towels-are-for-wimps-and-old-bay-can-really-grease-a-laptop's- keyboard-not-to-mention-the-wild-goose-ly y'rs, -Barry From claw@kanga.nu Wed Jul 17 08:32:04 2002 From: claw@kanga.nu (J C Lawrence) Date: Wed, 17 Jul 2002 00:32:04 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: Message from barry@zope.com (Barry A. Warsaw) of "Wed, 17 Jul 2002 03:28:31 EDT." <15669.7327.733812.68665@anthem.wooz.org> References: <15668.37417.657983.567997@anthem.wooz.org> <22091.1026881448@kanga.nu> <15669.7327.733812.68665@anthem.wooz.org> Message-ID: <24900.1026891124@kanga.nu> On Wed, 17 Jul 2002 03:28:31 -0400 Barry A Warsaw wrote: >>>>>> "JCL" == J C Lawrence writes: JCL> I don't supply mboxes (or any other raw form of my archives). JCL> Providing mboxes or some other off-line form of the archives is the JCL> most common archive-related request I receive. > I'd like to better understand the motivation for those requests. In > my cases I think it's because Pipermail archives don't give you two > important things: posting replies via the web, and the ability to > forward archive messages to an email address. Note: I don't use pipermail and my archives do support posting replies to the list via the web. (Details are in the FAQ) I don't currently support sending the original of an archives messages to a specified address. The most common (almost 100%) reasoning given for wanting an off-line for is easy of searching and reference. >>> Any chance you could make it down to DC for a side trip? We could >>> have a Mailman hacking sprint over a few dozen steamed Maryland blue >>> crabs and some cold ones. :) JCL> You might just drag me out to the other coast with offers like JCL> that. > August and September are prime crab-pickin' months y'know, and even > though they're expensive this year, I'm not adversed to a quick > morning hop down to the Eastern Shore for a bushel of jumbos. :) Hehn. I'm originally from the Balitmore area. Me and my gut know munchin' crabs quite well. -- 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 barry@zope.com Wed Jul 17 08:33:25 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 17 Jul 2002 03:33:25 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... References: <200207162011.31975.philb@philb.us> <22438.1026882548@kanga.nu> Message-ID: <15669.7621.189334.147861@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: JCL> Nothing. BUT, if the addresses are date limited the number JCL> of addresses in the valid pool is going to tend to be small JCL> (ie number of posters within the last window). This perforce JCL> forces SPAM harvesters to constant updating of their lists JCL> and a resultant huge rate of bad addresses. Plus, if you do server alias replacement, you have another technique at your disposal -- you can quarantine messages for some amount of time and watch for multiple copies to your aliases. List admins would be able to move the lever between more immediate delivery and longer quarantines as an anti-spam device. -Barry From claw@kanga.nu Wed Jul 17 08:37:36 2002 From: claw@kanga.nu (J C Lawrence) Date: Wed, 17 Jul 2002 00:37:36 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: Message from barry@zope.com (Barry A. Warsaw) of "Wed, 17 Jul 2002 03:33:25 EDT." <15669.7621.189334.147861@anthem.wooz.org> References: <200207162011.31975.philb@philb.us> <22438.1026882548@kanga.nu> <15669.7621.189334.147861@anthem.wooz.org> Message-ID: <25166.1026891456@kanga.nu> On Wed, 17 Jul 2002 03:33:25 -0400 Barry A Warsaw wrote: >>>>>> "JCL" == J C Lawrence writes: JCL> Nothing. BUT, if the addresses are date limited the number of JCL> addresses in the valid pool is going to tend to be small (ie number JCL> of posters within the last window). This perforce forces SPAM JCL> harvesters to constant updating of their lists and a resultant huge JCL> rate of bad addresses. > Plus, if you do server alias replacement, you have another technique > at your disposal -- you can quarantine messages for some amount of > time and watch for multiple copies to your aliases. List admins would > be able to move the lever between more immediate delivery and longer > quarantines as an anti-spam device. Oooooooooo! I like it. The delay wouldn't even have to be large as the typical volumes would be small (thus making the overhead manageable). A couple hours would be just fine for >80% of the cases. -- 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@plaidworks.com Wed Jul 17 15:12:31 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 17 Jul 2002 07:12:31 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <15669.7327.733812.68665@anthem.wooz.org> Message-ID: On 7/17/02 12:28 AM, "Barry A. Warsaw" wrote: > >>>>>> "JCL" == J C Lawrence writes: > > JCL> I don't supply mboxes (or any other raw form of my archives). > JCL> Providing mboxes or some other off-line form of the archives > JCL> is the most common archive-related request I receive. > > I'd like to better understand the motivation for those requests. I get these requests, too. Some kind of "easy way to download the entire archives" -- from people who want a local copy for local searching (grep, etc). Unfortunately, since that also makes it trivial to harvest off of, I tell these folks I won't do that. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Someday, we'll look back on this, laugh nervously and change the subject. From chuqui@plaidworks.com Wed Jul 17 15:39:48 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 17 Jul 2002 07:39:48 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <25166.1026891456@kanga.nu> Message-ID: On 7/17/02 12:37 AM, "J C Lawrence" wrote: > Oooooooooo! I like it. The delay wouldn't even have to be large as the > typical volumes would be small (thus making the overhead manageable). A > couple hours would be just fine for >80% of the cases. And we're just one small step from there to offering IMAP and webmail support, and going into business as our own ISP... Oh, wait. Forget I said that. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ The first rule of holes: If you are in one, stop digging. From laurence@digitalpulp.com Mon Jul 15 21:34:51 2002 From: laurence@digitalpulp.com (Laurence Berland) Date: Mon, 15 Jul 2002 16:34:51 -0400 Subject: [Mailman-Developers] Modifying mailman to filter archived messages Message-ID: <200207151634.51587.laurence@digitalpulp.com> Sent this to Mailman-users earlier, but am now thinking it is more approp= riate=20 here... All, =09I'm trying to modify mailman to simplify some tasks. Currently, sysad= mins get various emails from LogWatch every day or so that need to be read thr= ough in depth and then saved to some mailbox somewhere. This both takes a lot= of time and creates lots of private copies of these messages, which is bad. =09The simple part of this is to instead have the emails go to a mailman = list that these people may or may not choose to subscribe to, so that mailman = will archive the messages and let people choose whether or not to receive them without the intervention of others. The tough part is status coding. I'= ve already modified LogWatch (and will modify other email-sending scripts su= ch as our backup scripts) to code certain lines based on whether or not they require attention. Example 0: means "fine" or "green" and 2: means "trou= ble" or "red". What I'd like mailman to do is trap these strings such as "0:" "1:" etc and replace them with something else. Is there a particularl ea= sy way to do this? If not, where in the code could I conceivably do this. = I've been briefly skimming the code, and intend to read through quite a bit of= it to figure all this out, but if anyone could at least point me in the righ= t direction it'd make me very happy. Thanks for your help, Laurence Berland ------------------------------------------------------- ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py ------------------------------------------------------- From laurence@digitalpulp.com Wed Jul 17 15:52:01 2002 From: laurence@digitalpulp.com (Laurence Berland) Date: Wed, 17 Jul 2002 10:52:01 -0400 Subject: [Mailman-Developers] Extending mailman (adding config options) Message-ID: <200207171052.01835.laurence@digitalpulp.com> Those of you following my previous emails (lamentably unanswered so far) = will=20 already know that I'm trying to extend mailman to add color-coded graphic= s to=20 the archives to parse logwatch emails and such more efficiently. I'd like to have this configurable from the archive options page, so I wa= s=20 wondering what the standard structure for adding options is. Is there a=20 premade set of mailman functions for extending this in a standard and=20 non-kldugy way, and are they accessible as is from HyperArch.py? TIA, Laurence From jra@baylink.com Wed Jul 17 16:27:27 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 17 Jul 2002 11:27:27 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <23022.1026884875@kanga.nu>; from J C Lawrence on Tue, Jul 16, 2002 at 10:47:55PM -0700 References: <23022.1026884875@kanga.nu> Message-ID: <20020717112727.02682@scfn.thpl.lib.fl.us> On Tue, Jul 16, 2002 at 10:47:55PM -0700, J C Lawrence wrote: > On Tue, 16 Jul 2002 22:34:51 -0700 > Chuq Von Rospach wrote: > > What happens when someone sees an address in the archive six months > > from now and needs to contact that author? > > Is that really a valid and interesting case that can't be (usually) > handled by posting directly to the list? Absolutely, positively, 100% guaranteed. Think Google. Think 5-year old message with *almost* exactly the answer you need. Think "hasn't been on that mailing list in 2 years, since a bogus bounce dropped me and I didn't bother re-upping." Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From jra@baylink.com Wed Jul 17 16:39:51 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 17 Jul 2002 11:39:51 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: ; from Chuq Von Rospach on Tue, Jul 16, 2002 at 10:33:20PM -0700 References: <20020717002253.14548@scfn.thpl.lib.fl.us> Message-ID: <20020717113951.49775@scfn.thpl.lib.fl.us> On Tue, Jul 16, 2002 at 10:33:20PM -0700, Chuq Von Rospach wrote: > On 7/16/02 9:22 PM, "Jay R. Ashworth" wrote: > > Well, ok... but in a case like that, your mailer logs would likely have > > the appropriate information. But still, as rare as such a circumstance > > is, I don't see that you have any moral obligation to be *that* prepared. > > How many people keep their logs three weeks? How many people long ago > stopped keeping detailed SMTP logs because of their size? And rare as the > circumstance is, if YOUR house was burned down, would you still care that it > was rare? (it's real easy to say "don't care, it's someone else's house...") No, but I wouldn't hold the list op responsible for not keeping the info, if not keeping the info was their policy all along. I might *yell at them*, cause I think it's a stupid policy, but that's a llama of a different color... > > Stipulated. But I don't believe that the toaster *is* cheap and shoddy > > -- ie: that it's *your* responsibility -- merely because people break > > into your house, and jam oversized bagels into your toaster repeatedly > > until it won't hold toast anymore. > > Take a look at the court system. You're so far in the minority it's not > funny (really not funny). Have you ever read the instruction manual for a > toaster? The warning pages in the instruction manual, that say things like > "do not use toaster in shower"? Because if they DON'T say that, they get > sued because someone does? Case law? Yes, there are silly disclaimers, yes some of them correspond directly to cases. Hair dryer in shower, yes. *Toaster*? Naw; if that has a shower disclaimer, it's merely ass-covering. > > Except that the spam isn't the *problem*. The *spammers* are. > > Sorry. That's like saying "bullets aren't a problem, guns are". If you get > shot, you don't waste time arguing semantics like this. Unless, I guess, > you're a libertarian. But frankly, most of the libertarians I know who HAVE > been shot (instead of arguing about what they'd do if, theoretically, they > were shot) stop arguing semantics, too. No, neither bullets *nor* guns are the problem: *CRIMINALS ARE*. I sometimes question why I have to keep pointing that out. I call your attention, on the side topic, to Kennesaw, Georgia, the town that instituted the city ordinance some years ago *requiring* all heads to household to keep firearms: http://www.mcsm.org/kennesaw.html I *really* think this is pertinent, I'm not just trying to change the subject. How many libertarians do you know who have been shot? How many of them were shooters, themselves? > > Even when they get unreasonably strident, and scream for all the wrong > > reasons -- and they do -- I still back the Second Amendment > > absolutists, because history has proven that they *put that amendment > > in there for a reason*. > > That would be a fun argument, but I'll spare the list. Pass. (but if you > look at the historical record of the debates over the amendment, it's a lot > more ambiguous what the founding fathers THOUGHT, vs. how it's been > interpreted. But, pass...) "for the common defense" was loudly shouted down as clouding the point; that's good enough for me. If you're interested in bandying this, we can do it off list; maybe I'll learn something. :-) > > It is largely because of RMS' intransigience on many points related to > > Free Software that we have most of it, and most particularly Linux -- > > I really don't believe it would have happened at all except for the > > developer-protection provided by the GPL. > > And off we go into left field, to blame something completely tangential to > the issue at hand. > > Oh, never mind, pass. > > > Sometimes a cigar *is* just a cigar. > > That's what monica said, too. > > > Sometimes, you've got to let junior take the fall. > > Why? How very libertarian of you. May you never find someone calling you > junior... (it's easy to say "let them eat cake" when you aren't starving > with them. At least until the wagon arrives....) > > > Not at all. It's not a question of ease. Undertaking responsibility > > is not easy. > > No, ducking responsibility is easy. Undertaking responsbility, however, is > how things get done. > > > Someone has to fix the problem. It has been proven to my satisfaction > > that the technologists can't: it's not a technology-fix problem (so few > > 'problems' are). Someone has to get *pissed*. > > > > That'd be the people with the mailboxes, Bob. > > Wrong. It's the people with the skillset. Lots of people have mailboxes. Few > people have the skillsets. But those people, it seems, are willing to let > others rot, because it's easier for them personally. Well, some of them. You may choose to think that this is my real motivation if you're so inclined. If I think that people who don't want to be swamped in spam ought to learn how to use the already available tools to avoid it, and you think that makes me elitist, so be it; I've been called elitist before. > Look, if I wanted easy, I wouldn't even be on this list. I'd just download > tarballs and do what I felt like. I'd like to think we're all on this list > because we're better than that. Well, that sounds like a fairly broad ad hominem... but I think you're better than that. ;-) > > Fine. > > > > But this isn't procmail, nor SpamAssassin; they're at the other end of > > the hall; third and fifth doors on the right, respectively. > > > > This is a mailing list program. > > This is a tool that users attach trust to, and that trust is that we won't > abuse their mailbox and will send them what we tell them we'll send them. If > they stop trusting the tool, they'll stop using it. So we have a > responsibility (if not to those users, to the TOOL) to do what we can to > protect that trust a user attaches to the program when they agree to > subscribe to a mail list through it. > > > Letting spam through likely only gets you yelled at; accidentally > > blocking important stuff gets you burned. > > No, actually, both get you yelled at and/or burned, depending on who gets > upset about what. At some level, it's a no-win situation.... Yeah; great, ain't it? Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From claw@kanga.nu Wed Jul 17 16:42:52 2002 From: claw@kanga.nu (J C Lawrence) Date: Wed, 17 Jul 2002 08:42:52 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: Message from "Jay R. Ashworth" of "Wed, 17 Jul 2002 11:27:27 EDT." <20020717112727.02682@scfn.thpl.lib.fl.us> References: <23022.1026884875@kanga.nu> <20020717112727.02682@scfn.thpl.lib.fl.us> Message-ID: <29406.1026920572@kanga.nu> On Wed, 17 Jul 2002 11:27:27 -0400 Jay R Ashworth wrote: > On Tue, Jul 16, 2002 at 10:47:55PM -0700, J C Lawrence wrote: >> On Tue, 16 Jul 2002 22:34:51 -0700 Chuq Von Rospach >> Is that really a valid and interesting case that can't be (usually) >> handled by posting directly to the list? > Absolutely, positively, 100% guaranteed. > Think Google. Think 5-year old message with *almost* exactly the > answer you need. Think "hasn't been on that mailing list in 2 years, > since a bogus bounce dropped me and I didn't bother re-upping." Yup, which is a small enough probability of happening, with a small enough population who might even/ever want to do that, with a small enough probability of the original address even remaining valid over that time...etc that I don't see it as much of an interesting case. The (nicer) thing is that it also handles given a CGI which does reply-to-list from the web archives. ObNote: I have that feature on the archives at Kanga.Nu. -- 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 jra@baylink.com Wed Jul 17 16:46:03 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 17 Jul 2002 11:46:03 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: ; from Chuq Von Rospach on Tue, Jul 16, 2002 at 10:44:41PM -0700 References: <20020717004943.05209@scfn.thpl.lib.fl.us> Message-ID: <20020717114603.25175@scfn.thpl.lib.fl.us> On Tue, Jul 16, 2002 at 10:44:41PM -0700, Chuq Von Rospach wrote: > On 7/16/02 9:49 PM, "Jay R. Ashworth" wrote: > > You can document your policies, and the person who wants to sign up can > > decide whether they can deal. > > I don't think that's always good enough. You have to do what you can to back > the policies up. Unless, of course, your policy is "you're screwed if you > post to my list, and good luck stopping the spammers". Which is, > effectively, what "make the owner of the mailbox handle it" does as a > policy. Although I doubt you'd phrase it quite that way... I was on 14 mailing list for 6 years; I saw no appreciable amount of spam *at all*... > Heh. Wanna guarantee messages get bounced all over the place? Just use the > "V" word in an email. You know which one I mean. You'll set off alarms all > over the universe. It's more fun than running through a parking lot seeing > which cars have movement detectors on the alarms. Not that, um, I do that, > you know. > > Yeah. I keep forgetting that not everyone has spent 17 years on > > Usenet. > > Newbie. I can still remember the month that I ceased to be able to read *the entire feed*. I'm not *that* much of a newbie; though, admittedly, B2.9 is about the oldest news system I had to deal with. > > But that brings us almost immediately around to "why use email to do a > > Usenet's job"... which *LOTS* of mailing lists are doing, frankly. > > Because usenet is so broke none of us even think of fixing it any more? People tell me that all the time. I use slrn... and I don't see it, much. > I love to say "if all you have his a hammer, everything is a nail". In this > case, email is our hammer, and mail lists aren't always appropriate for > hammering, but have you seen what those idiots did to our screwdriver? I > ain't picking that up, not without tongs and a blowtorch. Perhaps I'm lucky, perhaps I'm blind... > > You've jumped ship before. So have I. > > Hell, I turned jumping ship into an art form. I know; I saw the website. :-) > In my heyday, usenet people > set their clocks by it. Well, maybe their calendars. :-) > I finally grew up, too, and learned to both manage my stress levels and > accept my responsibilities. I construed jumping ship *as* doing those things. > > They'll learn, eventually. > > Not that I've noticed. Well, stupidity is supposed to be expensive. And painful. > >> We're working on that (a quiet voice whispers: "but a f---ing mac already! > >> It has unix inside for all you geeks, too!") > > > > > > Heh. A unix box with a pretty damn good gui, in a lap top so you can carry > it anywhere, for about a grand. Effing wow. :-) > > My sister runs a page that's always in the top 3 on Google in her > > keyword, on a user-named account on Mind-link. Been there over 6 years > > now. She's had a pseudo-bogus address in her POP3 domain buried in a > > mailto: on there for over a year. > > > > *One* piece of spam. > > I am amazed. I have just +hacked the mailto that is in *my* weblog as the comment address. We'll see what happens. I'm not all that important, but... > > She's not exactly a low profile target. > > > > You, OTOH, are. How well "hidden" were your honeypot machines? > > "plaidworks.com" is likely not a low-profile domain, neither. > > You flatter me. I think. Maybe. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From noreply@sourceforge.net Wed Jul 17 16:46:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 17 Jul 2002 08:46:56 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-582891 ] Mailman converting = to =3D Message-ID: Bugs item #582891, was opened at 2002-07-17 15:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=582891&group_id=103 Category: (un)subscribing Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Jake Rosenbalm (jakerose) Assigned to: Nobody/Anonymous (nobody) Summary: Mailman converting = to =3D Initial Comment: We have a page allowing a user to submit thier email to subscribe to lists. The text sent is subscribe nodigest address=jakerose@yahoo.com. However, the coomand being processed by mailman is subscribe nodigest address=3Djakerose@yahoo.com, where the = is converted to =3D. ANy ideas? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=582891&group_id=103 From jra@baylink.com Wed Jul 17 16:47:40 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 17 Jul 2002 11:47:40 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: ; from Chuq Von Rospach on Tue, Jul 16, 2002 at 11:46:12PM -0700 References: <15669.4372.352349.350097@anthem.wooz.org> Message-ID: <20020717114740.30988@scfn.thpl.lib.fl.us> On Tue, Jul 16, 2002 at 11:46:12PM -0700, Chuq Von Rospach wrote: > Sorry, I just don't think they'l suceed at nuking free software. Too much > big business depends on it now. Vigilance is good, but when push comes to > shove, the ones that are trying to screw it up won't succeed. > > Besides, fi the US outlaws it, like, oh, stem cell research, it'll just > slide overseas out of the US jurisdiction, and the US will find that over > time, it'll be ata competitive disadvantage because of it... You haven't been following the SSSCA/CBDPTA traffic, have you. It will be illegal, but more importantly, it simply won't *run* -- you can't store data on the hard drive if you don't have the encryption keys to talk to it. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From chuqui@plaidworks.com Wed Jul 17 16:50:14 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 17 Jul 2002 08:50:14 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <20020717113951.49775@scfn.thpl.lib.fl.us> Message-ID: On 7/17/02 8:39 AM, "Jay R. Ashworth" wrote: > No, but I wouldn't hold the list op responsible for not keeping the > info, YOU wouldn't, but that's not the typical response. It's unsafe to take "my response" and use it to generalize to "all users", unless you really know you're thinking like the average/typical user. >> Take a look at the court system. You're so far in the minority it's not >> funny (really not funny). Have you ever read the instruction manual for a >> toaster? The warning pages in the instruction manual, that say things like >> "do not use toaster in shower"? Because if they DON'T say that, they get >> sued because someone does? > > Case law? Yes, there are silly disclaimers, yes some of them > correspond directly to cases. Hair dryer in shower, yes. *Toaster*? > Naw; if that has a shower disclaimer, it's merely ass-covering. You may see it as ass-covering. Have you talked to your lawyers recently about these issues? I have. Not fun, either. >>> Except that the spam isn't the *problem*. The *spammers* are. >> >> Sorry. That's like saying "bullets aren't a problem, guns are". If you get >> shot, you don't waste time arguing semantics like this. Unless, I guess, >> you're a libertarian. But frankly, most of the libertarians I know who HAVE >> been shot (instead of arguing about what they'd do if, theoretically, they >> were shot) stop arguing semantics, too. > > No, neither bullets *nor* guns are the problem: *CRIMINALS ARE*. Except that most people shot in their own home are shot by their own gun by someone they know, not a criminal. Or, at least, they're not a criminal until the bullet hits. You're strawmanning again, jay. This is, in fact, a great example in the real world of the situation I had this weekend in the email world. The poor idiot who spammed my users out of his address book wasn't a criminal -- until the minute he made that mistake in judgement and sent that e-mail. So while it's fun to run around screaming about the criminals being the problem, the most common problems we face are otherwise reasonable people who make mistakes or have lapses in judgement, not the guy in the alley with the gun and the blackjack. But it's a lot easier to talk about criminals and build a rhetoric and avoid having to deal with the tough situation of finding ways to protect people from their lapses, where there was no conscious intent to do something. > I sometimes question why I have to keep pointing that out. Because you're having trouble convincing us you're right. Because you aren't. Because you're building a strawman that fits your philosophy but not the reality. >> interpreted. But, pass...) > > "for the common defense" was loudly shouted down as clouding the point; > that's good enough for me. If you're interested in bandying this, we > can do it off list; maybe I'll learn something. :-) Nope. Pass. I'm already too close to a philosophical argument that'll drive this list bonkers. I'm not crossing the line... I hope. > You may choose to think that this is my real motivation if you're so > inclined. Thank you. Because if it looks like a duck and smells like a duck, it rhymes with Niagara. Oh, wait.... > Well, that sounds like a fairly broad ad hominem... but I think you're > better than that. ;-) Yeah. Usually my ad hominens are more narrowly targeted. I'll try harder next time. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Someday, we'll look back on this, laugh nervously and change the subject. From chuqui@plaidworks.com Wed Jul 17 16:52:44 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 17 Jul 2002 08:52:44 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <20020717114603.25175@scfn.thpl.lib.fl.us> Message-ID: On 7/17/02 8:46 AM, "Jay R. Ashworth" wrote: > Perhaps I'm lucky, perhaps I'm blind... Your new nickname is Stevie Wonder! >> I finally grew up, too, and learned to both manage my stress levels and >> accept my responsibilities. > > I construed jumping ship *as* doing those things. Well, yeah. How about "manage my stress and accept my responsibilites is a more constructive manner...." > Well, stupidity is supposed to be expensive. And painful. (opens mouth. Declines straight line. Closes mouth) -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ IMHO: Jargon. Acronym for In My Humble Opinion. Used to flag as an opinion something that is clearly from context an opinion to everyone except the mentally dense. Opinions flagged by IMHO are actually rarely humble. IMHO. (source: third unabridged dictionary of chuqui-isms). From chuqui@PLAIDWORKS.COM Wed Jul 17 16:55:25 2002 From: chuqui@PLAIDWORKS.COM (Chuq Von Rospach) Date: Wed, 17 Jul 2002 08:55:25 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <20020717114740.30988@scfn.thpl.lib.fl.us> Message-ID: On 7/17/02 8:47 AM, "Jay R. Ashworth" wrote: > You haven't been following the SSSCA/CBDPTA traffic, have you. > > It will be illegal, but more importantly, it simply won't *run* -- you > can't store data on the hard drive if you don't have the encryption > keys to talk to it. Yes, I have, actually. And you'll notice, maybe, what company I work for. They have to get that onto our hard disks first. The lemmings might accept it (but given how quickly they're upgrading to Windows XP, I think maybe you underestimate their ability to realize when they're being screwed), but not all of the world are lemmings. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ IMHO: Jargon. Acronym for In My Humble Opinion. Used to flag as an opinion something that is clearly from context an opinion to everyone except the mentally dense. Opinions flagged by IMHO are actually rarely humble. IMHO. (source: third unabridged dictionary of chuqui-isms). From jra@baylink.com Wed Jul 17 17:17:23 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 17 Jul 2002 12:17:23 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <15669.6184.241555.954040@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, Jul 17, 2002 at 03:09:28AM -0400 References: <20020716204919.07257@scfn.thpl.lib.fl.us> <20020717002253.14548@scfn.thpl.lib.fl.us> <15669.6184.241555.954040@anthem.wooz.org> Message-ID: <20020717121723.13714@scfn.thpl.lib.fl.us> On Wed, Jul 17, 2002 at 03:09:28AM -0400, Barry A. Warsaw wrote: > JRA> There's an argument going on somewhere else right now -- I > JRA> thought it was bugtraq, but I seem to have misplaced the > JRA> message -- about whether email addresses can have an RHS that > JRA> terminates in a . > > JRA> The poster says no way, I say that 2821 and 1034/5 say yes. > > I'm not sure. 2822 would be the definitive RFC wouldn't it? I hoped someone would bite. :-) 2822 3.4.1 says that the *LHS* cannot have a trailing dot without quoting it... but in the next graf, it seems to punt the interpretation of "domain" to 1034. > -------------------- snip snip -------------------- > addr-spec = local-part "@" domain > local-part = dot-atom / quoted-string / obs-local-part > dot-atom = [CFWS] dot-atom-text [CFWS] > dot-atom-text = 1*atext *("." 1*atext) > atext = ALPHA / DIGIT / ; Any character except controls, > "!" / "#" / ; SP, and specials. > "$" / "%" / ; Used for atoms > "&" / "'" / > "*" / "+" / > "-" / "/" / > "=" / "?" / > "^" / "_" / > "`" / "{" / > "|" / "}" / > obs-local-part = word *("." word) > word = atom / quoted-string > atom = [CFWS] 1*atext [CFWS] > -------------------- snip snip -------------------- > > It would seem that the local-part can't end in a `.'. [ looks closer ] ... due to the interpretation of dot-atom-text. You're right, that *is* what the standard says, and I'm surprised they left it that way in the rewrite; that is *not* the way it should have been done. There are good reasons why you might want to terminate a domain name, even in email -- though mostly diagnostic ones, admittedly. > JRA> Someone has to fix the problem. It has been proven to my > JRA> satisfaction that the technologists can't: it's not a > JRA> technology-fix problem (so few 'problems' are). Someone has > JRA> to get *pissed*. > > In a different context, the same question: do you think the corporate > fraud reforms now being debated in congress will solve the problem? > People /are/ pissed and are demanding both technological and > non-technological fixes. But maybe it's just 3am and I'm starting to > hallucinate. ;) No, I think that contemplating prison time, even sweeping the golf traps at Eglin AFB, will adjust the threat estimate of the corporate execs making the judgement calls. No one's going to try to hijack an American plane ever again, either. :-} > > I can't give any definite examples to protect the people involved, but I > > know of a couple of people who've had their careers significantly impacted > > because of this stuff. Maybe not fatal, but third degree burns. > > JRA> The topic being false-positive-ly blocked "spam", aren't > JRA> those evidence for the prosecution, not the defense? > > False positives don't scare me, but that's because we've got at least > 5 volunteer postmasters screening the reports and rescuing probably 1 > message a week, if that. What happens when the true-positives start > making a stink because they demand that their spam get through? Commercial speech is not protected by the first amendment, and the theft-of-service people are likely to win the civil suits, IMHO (IANAL :-) > JRA> Letting spam through likely only gets you yelled at; > JRA> accidentally blocking important stuff gets you burned. > > JRA> We are on the critical path, folks. I know you know that, > JRA> but the explicit reminder isn't going to get me fired. > JRA> Fail-safe isn't just for aerospace anymore. > > In a way I agree, but by the same token, email is such a flakey system > throughout that I think people have fairly low expectations that a > message they send will get delivered, read, and answered. I don't think so, and I surmise that Chuq might not either... > If you > positively must get an answer to a question and in a hurry, email's a > lousy way to ensure that. Stipulate on that point, but still... Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From jra@baylink.com Wed Jul 17 17:18:38 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 17 Jul 2002 12:18:38 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <15669.6891.666046.300064@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, Jul 17, 2002 at 03:21:15AM -0400 References: <20020716205740.62150@scfn.thpl.lib.fl.us> <20020717004943.05209@scfn.thpl.lib.fl.us> <15669.6891.666046.300064@anthem.wooz.org> Message-ID: <20020717121838.00836@scfn.thpl.lib.fl.us> On Wed, Jul 17, 2002 at 03:21:15AM -0400, Barry A. Warsaw wrote: > >>>>> "JRA" == Jay R Ashworth writes: > JRA> Barry? You've been cowering in the corner there, letting us > JRA> imitate Spenser and Hawk working up to it; comments? :-) > > What's my budget and where's my staff? :) Your staff is me and Chuqui; *what* kind of beer did you say that was on offer? ;-) Cheers, -- jr 'am I allowed to use the diminutive?' a -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From jerry@sandiego.edu Wed Jul 17 16:51:25 2002 From: jerry@sandiego.edu (Jerry Stratton) Date: Wed, 17 Jul 2002 08:51:25 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <20020716185552.54136@scfn.thpl.lib.fl.us> References: <20020716185552.54136@scfn.thpl.lib.fl.us> Message-ID: Jay R. Ashworth wrote: >So what are you going to do? > >Outlaw Outlook? > >:-) > Don't laugh--one of the filters we provide our users is "it says it came from Outlook" and "it has an attachment". Users can choose that if both of those conditions are met, the message is bounced back to the sender with an explanation that they don't accept Outlook mail that contains attachments! John Baxter wrote: >Plus, I fear the "new breed" spammers (the ones who actually think their >advertising is useful and welcome and only sent to opt-in lists, although >they buy the lists from guys who [figuratively] sell them from under a >trenchcoat at the entrance to a dark alley) will cause legislation to be >passed forbidding filtering at the mail server level. It nearly happened >last time around. I don't understand why people can't look at history. Get the government involved in spam legislation, and eventually businesses will convince the government to require us to receive spam. Jerry -- jerry@sandiego.edu http://www.sandiego.edu/~jerry/ Serra 188B/x8773 -- The more restrictions there are, the poorer the people become. The greater the government's power, the more chaotic the nation would become. The more the ruler imposes laws and prohibitions on his people, the more frequently evil deeds would occur. --The Silence of the Wise: The Sayings of Lao Zi From jra@baylink.com Wed Jul 17 17:22:12 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 17 Jul 2002 12:22:12 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: ; from Satya on Tue, Jul 16, 2002 at 11:56:16PM -0700 References: Message-ID: <20020717122212.08690@scfn.thpl.lib.fl.us> On Tue, Jul 16, 2002 at 11:56:16PM -0700, Satya wrote: > On Jul 16, 2002 at 22:44, Chuq Von Rospach wrote: > >On 7/16/02 9:49 PM, "Jay R. Ashworth" wrote: > > >the policies up. Unless, of course, your policy is "you're screwed if you > >post to my list, and good luck stopping the spammers". Which is, > >effectively, what "make the owner of the mailbox handle it" does as a > >policy. Although I doubt you'd phrase it quite that way... Note that the attribs are slightly hosed there; that's Chuq. > I wouldn't, but that would be my policy, yes. OTOH, no one pays me to > run mailing lists. > > Again, it's the same thing: have the mechanism (I'm not even sure > *which* mechanism(s) you're talking about now), let $foo decide the > policy, where $foo iterates over the list of users. The mechanism is "permit the hooking in of a method for preventing spam from reaching the list", I think. > Of course, that causes one person's miscalculation to be another > person's (times n) headache. Networks are like that. Yep. > >Heh. Wanna guarantee messages get bounced all over the place? Just use the > >"V" word in an email. You know which one I mean. You'll set off alarms all > > "virus"? Something else? VD? What? Vger. > (Insert Picard's speech about drawing the line here.) That was *precisely* what was running through my mind; only saw that movie 5 days ago. > >> My sister runs a page that's always in the top 3 on Google in her > >> *One* piece of spam. > >I am amazed. > > So am I. I mean, *one*? One. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From barry@zope.com Wed Jul 17 20:57:54 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 17 Jul 2002 15:57:54 -0400 Subject: [Mailman-Developers] Re: multiple addresses in (was AOL and odd) Reply-to (fwd) References: <22891.1026884214@kanga.nu> Message-ID: <15669.52290.648283.76160@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: Tamkin> It seems to me, though, that the list membership would be Tamkin> better served with this form: Tamkin> Reply-To: postauthor@its.domain, Tamkin> listname@listserver.domain Tamkin> because the MUAs with which I'm familiar make it anywhere Tamkin> from slightly easier to far easier for the respondent to Tamkin> remove addresses from the right of the reply's To: than Tamkin> from the left. Seems easy enough and harmless so ok, implemented. -Barry From barry@zope.com Wed Jul 17 21:08:19 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 17 Jul 2002 16:08:19 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... References: <15669.4372.352349.350097@anthem.wooz.org> Message-ID: <15669.52915.962983.528327@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: >> Wow, I guess you don't read many EULAs do ya? :) >> your-problem-son-is-ya-got-morals-ly y'rs, CVR> I can sleep at night, too. But then, I believe in doing what CVR> I think is right, not what I can get away with as legal. If CVR> that bothers you, sue me... CVR> (heh) Now we understand why neither of us are CEOs of large US corporations, or high ranking US goverment officials. :) >> P.S. Someday soon you/we may indeed have that legal >> responsibility. Although obviously a worthy goal, I'm actually >> a little fearful of what that'll mean for free software. CVR> Sorry, I just don't think they'l suceed at nuking free CVR> software. Too much big business depends on it now. Vigilance CVR> is good, but when push comes to shove, the ones that are CVR> trying to screw it up won't succeed. You're definitely more optimistic than I am. When Hollywood, the RIAA, and Microsoft team up against it, and the h/w manufacturers capitulate or risk being tarred as un-Americans aiding cyberterrorism I think we have an up-Hill (sic) battle. can-we-kill-this-thread-now?-ly y'rs, -Barry From barry@zope.com Wed Jul 17 21:25:17 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 17 Jul 2002 16:25:17 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... References: <200207162011.31975.philb@philb.us> <22438.1026882548@kanga.nu> <15669.7621.189334.147861@anthem.wooz.org> <25166.1026891456@kanga.nu> Message-ID: <15669.53933.428997.746794@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: JCL> Oooooooooo! I like it. The delay wouldn't even have to be JCL> large as the typical volumes would be small (thus making the JCL> overhead manageable). A couple hours would be just fine for JCL> >80% of the cases. I'd think so too. Hell some messages stay in the admindb queue for months and people don't complain /too/ much. ;) -Barry From JasonR.Mastaler Wed Jul 17 21:28:34 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Wed, 17 Jul 2002 14:28:34 -0600 Subject: [Mailman-Developers] Re: Opening up a few can o' worms here... References: Message-ID: Chuq Von Rospach writes: > We're going to be implementing TMDA to do this, and will be > switching all admin to generic addresses that filter through TMDA, > as well as things like postmaster@ and the like. Glad to hear this. AFAIK, TMDA isn't currently in use at any huge sites, so this should be a good test. > I'm going to look and see if I can interface TMDA to the subscriber > databases so that subscribers are by definition whitelisted The docs cover the details, but yes TMDA can do this. For example, the filter for the tmda-workers mailing list includes the following lines: # allow subscribers through from-mailman -attr=members ~mailman/lists/tmda-workers ok # ditto for digest subscribers from-mailman -attr=digest_members ~mailman/lists/tmda-workers ok -- (http://tmda.net/) From JasonR.Mastaler Wed Jul 17 21:33:44 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Wed, 17 Jul 2002 14:33:44 -0600 Subject: [Mailman-Developers] Re: Opening up a few can o' worms here... References: <21585.1026880794@kanga.nu> Message-ID: J C Lawrence writes: > Note that TMDA handling is trivially automated by SPAMmers and that > they will so automatically handle and bypass TMDA as soon as it > becomes popular enough for them to notice. Not necessarily. See http://tmda.net/faq.cgi?req=show&file=faq01.001.htp -- (http://tmda.net/) From barry@zope.com Wed Jul 17 21:34:24 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 17 Jul 2002 16:34:24 -0400 Subject: [Mailman-Developers] Extending mailman (adding config options) References: <200207171052.01835.laurence@digitalpulp.com> Message-ID: <15669.54480.382002.194754@anthem.wooz.org> >>>>> "LB" == Laurence Berland writes: LB> Those of you following my previous emails (lamentably LB> unanswered so far) will already know that I'm trying to extend LB> mailman to add color-coded graphics to the archives to parse LB> logwatch emails and such more efficiently. LB> I'd like to have this configurable from the archive options LB> page, so I was wondering what the standard structure for LB> adding options is. Is there a premade set of mailman LB> functions for extending this in a standard and non-kldugy way, LB> and are they accessible as is from HyperArch.py? I'm not totally sure what you're asking about, but there is definitely a recipe for adding new mailing list configuration options. Briefly outlined: - Decide on an attribute name (or names if there are more than one). Be sure they don't collide with existing names. - Decide what the data type will be ("bool", int, strings) -- for simplicity try to stick to one of the 13 existing "Enumeration for Mailman cgi widget types" defined in Defaults.py.in - Add attribute init code for newly created lists. For archiver/pipermail options, these would go in Archiver.InitVars() in Mailman/Archiver/Archiver.py - Add support for "schema updating" for existing lists. If you're adding new config options, this probably means adding a few lines to NewVars() in Mailman/versions.py - Bump the DATA_FILE_VERSION so the schemas will auto-update on next MailList object load. - Add the gui goo (i.e. the widget descriptions). For the archiver admin page, you're talking about adding to the returned list in Archive.GetConfigInfo() in Mailman/Gui/Archive.py. HTH, -Barry From JasonR.Mastaler Wed Jul 17 21:37:11 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Wed, 17 Jul 2002 14:37:11 -0600 Subject: [Mailman-Developers] Re: Opening up a few can o' worms here... References: <15668.37417.657983.567997@anthem.wooz.org> <22091.1026881448@kanga.nu> Message-ID: J C Lawrence writes: > My main complaint against TMDA is that it doesn't email an alert > message to me ala, "Bubba tried to email you and I'm holding his > message pending confirmation." Not true. See http://tmda.net/faq.cgi?req=show&file=faq01.006.htp > I'd like to know about held messages, or at least be able to > trivially know so that I can pro-actively act to white-list and > let mail thru without the other side having to jump thru rude > hoops. Somewhat related: http://tmda.net/faq.cgi?req=show&file=faq01.005.htp -- (http://tmda.net/) From barry@zope.com Wed Jul 17 21:42:57 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 17 Jul 2002 16:42:57 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... References: <23022.1026884875@kanga.nu> <20020717112727.02682@scfn.thpl.lib.fl.us> Message-ID: <15669.54993.549945.635673@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: >> Is that really a valid and interesting case that can't be >> (usually) handled by posting directly to the list? JRA> Absolutely, positively, 100% guaranteed. JRA> Think Google. Think 5-year old message with *almost* exactly JRA> the answer you need. Think "hasn't been on that mailing list JRA> in 2 years, since a bogus bounce dropped me and I didn't JRA> bother re-upping." Think "has changed jobs 3 times since then and one of them was a dot-bomb, moved ISPs twice, so good luck in tracking down /any/ valid email for the guy". -Barry From barry@zope.com Wed Jul 17 21:41:32 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 17 Jul 2002 16:41:32 -0400 Subject: [Mailman-Developers] Modifying mailman to filter archived messages References: <200207151634.51587.laurence@digitalpulp.com> Message-ID: <15669.54908.141903.520297@anthem.wooz.org> >>>>> "LB" == Laurence Berland writes: LB> What I'd like mailman to do is trap these strings such as "0:" LB> "1:" etc and replace them with something else. Is there a LB> particularl easy way to do this? If not, where in the code LB> could I conceivably do this. I've been briefly skimming the LB> code, and intend to read through quite a bit of it to figure LB> all this out, but if anyone could at least point me in the LB> right direction it'd make me very happy. A general approach would be to hack into the Mailman/Queue/ArchRunner.py file, ArchRunner._dispose() method. I'd write a separate "handler module", say Mailman/Handlers/OurStatusMunger.py which does the specifics of the transformation you're interested in. Although your situation is fairly unique, you might want to copy the API and style of other handler modules in that directory. Then add something to _dispose() that checks an attribute on the mlist object to decide whether to call into your handler module. I'd do the check like this: ... from Mailman.Handlers import OurStatusMunger ... if getattr(mlist, 'munge_status_p', 0): OurStatusMunger.process(mlist, msg, msgdata) ... and then use bin/withlist to add this attribute (set to 1 of course!) to just the list you want to do the extra processing on. Note that if you want to do this /before/ the message hits the archiver, e.g. you want it in the outgoing messages, you'd simply need to add the OurStatusMunger module to the GLOBAL_PIPELINE variable in Defaults.py.in -- another good reason to make OurStatusMunger.py conform to the handler API. -Barry From JasonR.Mastaler Wed Jul 17 21:38:49 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Wed, 17 Jul 2002 14:38:49 -0600 Subject: [Mailman-Developers] Re: Opening up a few can o' worms here... References: <22644.1026883220@kanga.nu> Message-ID: Chuq Von Rospach writes: >> How about a dated address which works transparently for a week then >> reverts to a TMDA-like filter for another fortnight, and then dies? > > What happens when someone sees an address in the archive six months > from now and needs to contact that author? When you send e-mail to an expired 'dated' address such as the one in my Reply-To header, TMDA will just prompt the sender for confirmation. This is the default behavior, but you can also configure it to drop, deliver or bounce mail to an expired dated address. -- (http://tmda.net/) From barry@zope.com Wed Jul 17 21:57:43 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 17 Jul 2002 16:57:43 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... References: <20020717002253.14548@scfn.thpl.lib.fl.us> <20020717113951.49775@scfn.thpl.lib.fl.us> Message-ID: <15669.55879.237194.1091@anthem.wooz.org> JRA> Yeah; great, ain't it? Futility can be fun! -Barry From chuqui@plaidworks.com Wed Jul 17 22:03:09 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 17 Jul 2002 14:03:09 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <15669.52915.962983.528327@anthem.wooz.org> Message-ID: On 7/17/02 1:08 PM, "Barry A. Warsaw" wrote: > You're definitely more optimistic than I am. When Hollywood, the > RIAA, and Microsoft team up against it, and the h/w manufacturers > capitulate or risk being tarred as un-Americans aiding cyberterrorism > I think we have an up-Hill (sic) battle. But there are a whole lotta other companies banding together to build stuff using open standards and open software. Apple today announced new work with sony erriccson and cingular on GPRS and bluetooth, for instance (kewl stuff), and is openly supporting open standards instead of trying to lock people into proprietary ones. Just because some companies are trying to wall off the internet doesn't mean they will. Remember, AOL tried that for years, and finally had to connect in and join the net, too. The net is going to prove pretty hard to kill. > can-we-kill-this-thread-now?-ly y'rs, Sure. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after From barry@zope.com Wed Jul 17 22:12:59 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 17 Jul 2002 17:12:59 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... References: <20020717113951.49775@scfn.thpl.lib.fl.us> Message-ID: <15669.56795.225237.819356@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> This is, in fact, a great example in the real world of the CVR> situation I had this weekend in the email world. The poor CVR> idiot who spammed my users out of his address book wasn't a CVR> criminal -- until the minute he made that mistake in CVR> judgement and sent that e-mail. So while it's fun to run CVR> around screaming about the criminals being the problem, the CVR> most common problems we face are otherwise reasonable people CVR> who make mistakes or have lapses in judgement, not the guy in CVR> the alley with the gun and the blackjack. But it's a lot CVR> easier to talk about criminals and build a rhetoric and avoid CVR> having to deal with the tough situation of finding ways to CVR> protect people from their lapses, where there was no CVR> conscious intent to do something. Ah, now here's our angle. We're actually fighting cyberterrorists. I can almost tastest the Department of Homeland Security grants. CVR> Nope. Pass. I'm already too close to a philosophical argument CVR> that'll drive this list bonkers. I'm not crossing the CVR> line... I hope. Thanks. While I love a fiesty political debate as much as the next guy (really!), this list is definitely off-topic for it. -Barry From barry@zope.com Wed Jul 17 22:26:11 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 17 Jul 2002 17:26:11 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... References: <20020716204919.07257@scfn.thpl.lib.fl.us> <20020717002253.14548@scfn.thpl.lib.fl.us> <15669.6184.241555.954040@anthem.wooz.org> <20020717121723.13714@scfn.thpl.lib.fl.us> Message-ID: <15669.57587.888415.651186@anthem.wooz.org> On Wed, Jul 17, 2002 at 03:09:28AM -0400, Barry A. Warsaw wrote: JRA> I hoped someone would bite. :-) :) JRA> 2822 3.4.1 says that the *LHS* cannot have a trailing dot JRA> without quoting it... but in the next graf, it seems to punt JRA> the interpretation of "domain" to 1034. Which circular references back to RFC 822. :) But anyway I thought we were talking about the localpart. JRA> You're right, that *is* what the standard says, and I'm JRA> surprised they left it that way in the rewrite; that is *not* JRA> the way it should have been done. There are good reasons why JRA> you might want to terminate a domain name, even in email -- --------------------------------------------------^ Did you leave out "with a dot" ? JRA> though mostly diagnostic ones, admittedly. Hmm, not a use case I've ever encountered. "localhost.localdomain" is about as wacky as it gets. -Barry From barry@zope.com Wed Jul 17 22:27:48 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 17 Jul 2002 17:27:48 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... References: <20020716205740.62150@scfn.thpl.lib.fl.us> <20020717004943.05209@scfn.thpl.lib.fl.us> <15669.6891.666046.300064@anthem.wooz.org> <20020717121838.00836@scfn.thpl.lib.fl.us> Message-ID: <15669.57684.821840.544426@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> Your staff is me and Chuqui; *what* kind of beer did you say JRA> that was on offer? ;-) Wild Goose, but hey if you guys showed up for a Mailman sprint, I'd let you pick your own poison. -Barry From barry@zope.com Wed Jul 17 22:37:21 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 17 Jul 2002 17:37:21 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... References: <20020717122212.08690@scfn.thpl.lib.fl.us> Message-ID: <15669.58257.254219.569508@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> The mechanism is "permit the hooking in of a method for JRA> preventing spam from reaching the list", I think. Already exists, of course. SpamDetect is a lame-ass placeholder, but of course, the system is already architected for folks to add their own handler modules to do better. -Barry From claw@kanga.nu Wed Jul 17 22:41:08 2002 From: claw@kanga.nu (J C Lawrence) Date: Wed, 17 Jul 2002 14:41:08 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: Message from barry@zope.com (Barry A. Warsaw) of "Wed, 17 Jul 2002 16:25:17 EDT." <15669.53933.428997.746794@anthem.wooz.org> References: <200207162011.31975.philb@philb.us> <22438.1026882548@kanga.nu> <15669.7621.189334.147861@anthem.wooz.org> <25166.1026891456@kanga.nu> <15669.53933.428997.746794@anthem.wooz.org> Message-ID: <5145.1026942068@kanga.nu> On Wed, 17 Jul 2002 16:25:17 -0400 Barry A Warsaw wrote: >>>>>> "JCL" == J C Lawrence writes: JCL> Oooooooooo! I like it. The delay wouldn't even have to be large JCL> as the typical volumes would be small (thus making the overhead JCL> manageable). A couple hours would be just fine for >80% of the JCL> cases. > I'd think so too. Hell some messages stay in the admindb queue for > months and people don't complain /too/ much. ;) Which brings up a pair of features I'd love to see down the road: 1) Ability to annotate a message in the moderation queue. This is as simple as being able to associate a note with a given message which is then displayed (preferably highlighted) against the message in the queue. Invaluable for multiple moderator scenarios and damned useful for me as I tend to deliberately leave some messages in the queue for extended periods (days/weeks) and would like the reminders as to why. 2) Ability to sideline some messages from the moderation queue. They're still in the system, they're just in a different non-default queue. Again useful both in the multiple moderation case and my more unusual moderation style. -- 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 barry@zope.com Wed Jul 17 22:59:45 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 17 Jul 2002 17:59:45 -0400 Subject: [Mailman-Developers] Re: Opening up a few can o' worms here... References: <21585.1026880794@kanga.nu> Message-ID: <15669.59601.633501.291687@anthem.wooz.org> >>>>> "JRM" == Jason R Mastaler writes: JRM> Not necessarily. JRM> See http://tmda.net/faq.cgi?req=show&file=faq01.001.htp Basically you're trying to set up a Turing test, yes? -Barry From fil@rezo.net Wed Jul 17 23:29:46 2002 From: fil@rezo.net (Fil) Date: Thu, 18 Jul 2002 00:29:46 +0200 Subject: [Mailman-Developers] subjects still get double encoding... Message-ID: <20020717222946.GB24904@rezo.net> ... and I'm getting mad. I've tried prying into the code, but this is too tough for me. It definitely is happening during the IncomingRunner process, but all functions look neat. So where's the [pc]atch?? ;) -- Fil From JasonR.Mastaler Wed Jul 17 23:39:34 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Wed, 17 Jul 2002 16:39:34 -0600 Subject: [Mailman-Developers] Re: Opening up a few can o' worms here... References: <21585.1026880794@kanga.nu> <15669.59601.633501.291687@anthem.wooz.org> Message-ID: barry@zope.com (Barry A. Warsaw) writes: > Basically you're trying to set up a Turing test, yes? At this point, it's not necessary. The challenge currently needs to be no more more complex than confirming a mailing list subscription (i.e, "hit reply to confirm"). For reasons discussed in the my FAQ, it might not ever need to be either. In any case, should this change, there is work being done to derive tests than humans can pass, but computers cannot. For example, the CAPTCHA project (http://www.captcha.net/). I'm a believer in not trying to cross that bridge until we come to it though. -- (http://tmda.net/) From philb@philb.us Thu Jul 18 01:47:04 2002 From: philb@philb.us (Phil Barnett) Date: Wed, 17 Jul 2002 20:47:04 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: References: Message-ID: <200207172047.04056.philb@philb.us> On Wednesday 17 July 2002 10:39, Chuq Von Rospach wrote: > On 7/17/02 12:37 AM, "J C Lawrence" wrote: > > Oooooooooo! I like it. The delay wouldn't even have to be large as = the > > typical volumes would be small (thus making the overhead manageable).= A > > couple hours would be just fine for >80% of the cases. > > And we're just one small step from there to offering IMAP and webmail > support, and going into business as our own ISP... > > Oh, wait. Forget I said that. I have IMAP and webmail covered on my server... From jra@baylink.com Thu Jul 18 15:27:13 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Thu, 18 Jul 2002 10:27:13 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <15669.57587.888415.651186@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, Jul 17, 2002 at 05:26:11PM -0400 References: <20020716204919.07257@scfn.thpl.lib.fl.us> <20020717002253.14548@scfn.thpl.lib.fl.us> <15669.6184.241555.954040@anthem.wooz.org> <20020717121723.13714@scfn.thpl.lib.fl.us> <15669.57587.888415.651186@anthem.wooz.org> Message-ID: <20020718102713.53279@scfn.thpl.lib.fl.us> On Wed, Jul 17, 2002 at 05:26:11PM -0400, Barry A. Warsaw wrote: > JRA> 2822 3.4.1 says that the *LHS* cannot have a trailing dot > JRA> without quoting it... but in the next graf, it seems to punt > JRA> the interpretation of "domain" to 1034. > > Which circular references back to RFC 822. :) > > But anyway I thought we were talking about the localpart. No, I was talking about the domain part. The standard is pretty clear that the LHS can have anything in it you want, as long as you quote it. > JRA> You're right, that *is* what the standard says, and I'm > JRA> surprised they left it that way in the rewrite; that is *not* > JRA> the way it should have been done. There are good reasons why > JRA> you might want to terminate a domain name, even in email -- > --------------------------------------------------^ > Did you leave out "with a dot" ? No; domain names that end in a dot are referred to in jargon as "terminated" or "rooted". At least, the jargon I'm used to... > JRA> though mostly diagnostic ones, admittedly. > > Hmm, not a use case I've ever encountered. "localhost.localdomain" is > about as wacky as it gets. Well, diagnosing local DNS configuration, mostly. A name that does *not* end in a dot is supposed to be an invitation to apply the search list from /etc/resolv.conf. With people having things registered like com.com and edu.com, it can get a bit wacky. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From jra@baylink.com Thu Jul 18 15:24:26 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Thu, 18 Jul 2002 10:24:26 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: ; from Chuq Von Rospach on Wed, Jul 17, 2002 at 02:03:09PM -0700 References: <15669.52915.962983.528327@anthem.wooz.org> Message-ID: <20020718102426.48111@scfn.thpl.lib.fl.us> On Wed, Jul 17, 2002 at 02:03:09PM -0700, Chuq Von Rospach wrote: > On 7/17/02 1:08 PM, "Barry A. Warsaw" wrote: > > You're definitely more optimistic than I am. When Hollywood, the > > RIAA, and Microsoft team up against it, and the h/w manufacturers > > capitulate or risk being tarred as un-Americans aiding cyberterrorism > > I think we have an up-Hill (sic) battle. > > But there are a whole lotta other companies banding together to build stuff > using open standards and open software. Apple today announced new work with > sony erriccson and cingular on GPRS and bluetooth, for instance (kewl > stuff), and is openly supporting open standards instead of trying to lock > people into proprietary ones. > > Just because some companies are trying to wall off the internet doesn't mean > they will. Remember, AOL tried that for years, and finally had to connect in > and join the net, too. The net is going to prove pretty hard to kill. You obviously have not been following the activities of Senator Hollings, D-Disney, whose SSSCA indeed wants to make the very *design* of Linux illegal. Google for SSSCA. Check it out. *Apple* will likely be on the winning side. Linux wont, at least not in the bill's current shape. Please, nobody tell Hollings about CS First Boston and the NYSE, not to mention a large chunk of the backbone. I wanna see what happens when everyone just shuts their Linux boxes down because they've been declared illegal. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From dgc@uchicago.edu Thu Jul 18 18:34:37 2002 From: dgc@uchicago.edu (David Champion) Date: Thu, 18 Jul 2002 12:34:37 -0500 Subject: [Mailman-Developers] Re: Opening up a few can o' worms here... In-Reply-To: <20020718102426.48111@scfn.thpl.lib.fl.us> References: <15669.52915.962983.528327@anthem.wooz.org> <20020718102426.48111@scfn.thpl.lib.fl.us> Message-ID: <20020718173437.GV17367@dust.uchicago.edu> * On 2002.07.18, in <20020718102426.48111@scfn.thpl.lib.fl.us>, * "Jay R. Ashworth" wrote: > > You obviously have not been following the activities of Senator > Hollings, D-Disney, whose SSSCA indeed wants to make the very *design* > of Linux illegal. How does this conflict with the design of Linux (or, presumably, any other operating system)? Why is it not possible to integrate DRM support into Linux? > Please, nobody tell Hollings about CS First Boston and the NYSE, not to > mention a large chunk of the backbone. I wanna see what happens when > everyone just shuts their Linux boxes down because they've been > declared illegal. Existing systems are grandfathered. It's not clear (to me) whether this applies only to hardware devices, or also to software; or whether a device wishing to be grandfathered needs to be sponsored by some legal entity. Not that I support the SSSCA; I just think it pays better to fight on fair terms. -- -D. Fresh fruit enriches everyone. Takes the thirst ENSA, NSIT out of everyday time. A pure whiff of oxygen, University of Chicago painting over a monochrome world in primary colors. dgc@uchicago.edu We all know that. It's why everyone loves fruit. From barry@zope.com Thu Jul 18 19:21:05 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 18 Jul 2002 14:21:05 -0400 Subject: [Mailman-Developers] Re: Opening up a few can o' worms here... References: <15669.52915.962983.528327@anthem.wooz.org> <20020718102426.48111@scfn.thpl.lib.fl.us> <20020718173437.GV17367@dust.uchicago.edu> Message-ID: <15671.1809.892508.469774@anthem.wooz.org> >>>>> "DC" == David Champion writes: DC> Not that I support the SSSCA; I just think it pays better to DC> fight on fair terms. But not here, please. I know we've all got very strong feelings about these issues, but we need to keep this list focussed. Plus I don't have time to weed through all these messages. ;) list-mom-ish-ly y'rs, -Barry From jra@baylink.com Thu Jul 18 19:37:09 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Thu, 18 Jul 2002 14:37:09 -0400 Subject: [Mailman-Developers] Re: Opening up a few can o' worms here... In-Reply-To: <20020718173437.GV17367@dust.uchicago.edu>; from David Champion on Thu, Jul 18, 2002 at 12:34:37PM -0500 References: <15669.52915.962983.528327@anthem.wooz.org> <20020718102426.48111@scfn.thpl.lib.fl.us> <20020718173437.GV17367@dust.uchicago.edu> Message-ID: <20020718143709.35017@scfn.thpl.lib.fl.us> On Thu, Jul 18, 2002 at 12:34:37PM -0500, David Champion wrote: > * On 2002.07.18, in <20020718102426.48111@scfn.thpl.lib.fl.us>, > * "Jay R. Ashworth" wrote: > > > > You obviously have not been following the activities of Senator > > Hollings, D-Disney, whose SSSCA indeed wants to make the very *design* > > of Linux illegal. > > How does this conflict with the design of Linux (or, presumably, any > other operating system)? Why is it not possible to integrate DRM support > into Linux? Because the open design of Linux makes it impossible to *hide* the things which the law would required be hidden. I didn't make this stuff up; look here: http://www.linuxplanet.com/linuxplanet/opinions/3813/1/ http://www.troubleshooters.com/tpromag/200111/200111.htm#_SSSCAsBitterHarvest http://old.lwn.net/2001/1025/ http://www.sonic.net/~rknop/rant.html#sssca and a whole lotta buncha stuff here: http://dmoz.org/Society/Issues/Intellectual_Property/Copyrights/Consumer_Broadband_and_Digital_Television_Promotion_Act/News_and_Media/ one of the pieces in which is exceptionally good: http://www.networkcomputing.com/buzzcut/bc24sep01.html > > Please, nobody tell Hollings about CS First Boston and the NYSE, not to > > mention a large chunk of the backbone. I wanna see what happens when > > everyone just shuts their Linux boxes down because they've been > > declared illegal. > > Existing systems are grandfathered. It's not clear (to me) whether this > applies only to hardware devices, or also to software; or whether a > device wishing to be grandfathered needs to be sponsored by some legal > entity. The final outcome will be that no one will manufacture non-SSSCA compliant peripherals like, oh, *hard drives*... and since Linux will not be able to talk to the encrypted ones, it won't *matter* that it's considered a "circumvention device", it just won't be able to run at all. > Not that I support the SSSCA; I just think it pays better to fight on > fair terms. So do I. In consequence of which I'm not sure what you mean by that. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From barry@zope.com Thu Jul 18 19:19:19 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 18 Jul 2002 14:19:19 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... References: <20020716204919.07257@scfn.thpl.lib.fl.us> <20020717002253.14548@scfn.thpl.lib.fl.us> <15669.6184.241555.954040@anthem.wooz.org> <20020717121723.13714@scfn.thpl.lib.fl.us> <15669.57587.888415.651186@anthem.wooz.org> <20020718102713.53279@scfn.thpl.lib.fl.us> Message-ID: <15671.1703.200622.597668@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> No, I was talking about the domain part. Ok. JRA> The standard is pretty clear that the LHS can have anything JRA> in it you want, as long as you quote it. Yeah, but then it wouldn't /technically/ end in a dot, would it? :) Okay, okay, I'm being pedantic. >> Hmm, not a use case I've ever encountered. >> "localhost.localdomain" is about as wacky as it gets. JRA> Well, diagnosing local DNS configuration, mostly. A name JRA> that does *not* end in a dot is supposed to be an invitation JRA> to apply the search list from /etc/resolv.conf. JRA> With people having things registered like com.com and JRA> edu.com, it can get a bit wacky. Ah, ok. -Barry From jra@baylink.com Thu Jul 18 19:42:58 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Thu, 18 Jul 2002 14:42:58 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <15671.1703.200622.597668@anthem.wooz.org>; from "Barry A. Warsaw" on Thu, Jul 18, 2002 at 02:19:19PM -0400 References: <20020716204919.07257@scfn.thpl.lib.fl.us> <20020717002253.14548@scfn.thpl.lib.fl.us> <15669.6184.241555.954040@anthem.wooz.org> <20020717121723.13714@scfn.thpl.lib.fl.us> <15669.57587.888415.651186@anthem.wooz.org> <20020718102713.53279@scfn.thpl.lib.fl.us> <15671.1703.200622.597668@anthem.wooz.org> Message-ID: <20020718144258.18970@scfn.thpl.lib.fl.us> On Thu, Jul 18, 2002 at 02:19:19PM -0400, Barry A. Warsaw wrote: > >>>>> "JRA" == Jay R Ashworth writes: > JRA> No, I was talking about the domain part. > > Ok. > > JRA> The standard is pretty clear that the LHS can have anything > JRA> in it you want, as long as you quote it. > > Yeah, but then it wouldn't /technically/ end in a dot, would it? :) > Okay, okay, I'm being pedantic. Usually. In this case, you're actually incorrect, alas. The quotation marks are not semantically part of the address. So it *does* end in a dot. (Yes, I know you were being a smart ass.) > >> Hmm, not a use case I've ever encountered. > >> "localhost.localdomain" is about as wacky as it gets. > > JRA> Well, diagnosing local DNS configuration, mostly. A name > JRA> that does *not* end in a dot is supposed to be an invitation > JRA> to apply the search list from /etc/resolv.conf. > > JRA> With people having things registered like com.com and > JRA> edu.com, it can get a bit wacky. > > Ah, ok. Actually, a "bit" might be an understatement... Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From del@babel.com.au Thu Jul 18 15:10:59 2002 From: del@babel.com.au (Del) Date: Fri, 19 Jul 2002 00:10:59 +1000 Subject: [Mailman-Developers] some help required Message-ID: <3D36CC73.80002@babel.com.au> Hi, I run a web and e-mail server for a smallish non-profit association. I host it on a network that's owned by another third party, and since bandwidth costs are fairly high in Australia we have to be fairly careful about how we use our mailing lists. So far we've been using Mailman which appears to work fine and does nearly everything we want it to do, with the following exceptions: - We really need it to drop all attachments. This is for bandwidth conservation purposes, and although we have a rule that nobody's allowed to send attachments to the mailing list (or else the network owner gets grumpy with us), people still do, mostly because they are stupid, or don't know that the nice invitation they spent hours doing in photoshop is an "attachment". - We would like it to put the address of the original poster at the footer of the message, so that people can reply back to the poster rather than the list if they want to (and some mail programs are dumb enough to not display the poster's e-mail address as part of the header display). We have some of our lists set to reply to sender, but some are set to reply to list, so we want to give people both options. This is a feature that we used to have in majordomo, but maintaining majordomo lists was a lot more complicated than mailman with it's nice web interface and all. However, getting this done requires knowing python, and none of us know it. I have bashed my head against it a bit but it's another programming language as far as I'm concerned and I'm not all that good at that kind of stuff. Is it possible that someone on the mailman dev team could do some poor souls a favour and cut some code for us? Either on the current version of mailman that we're using (2.0.7) or on a later version -- I'm happy to upgrade provided it gets us the features we want. Thanks for any time and assistance you can provide, -- Del From dmick@west.sun.com Thu Jul 18 21:40:26 2002 From: dmick@west.sun.com (Dan Mick) Date: Thu, 18 Jul 2002 13:40:26 -0700 Subject: [Mailman-Developers] Well, Chuq... Message-ID: <3D3727BA.5040808@west.sun.com> ...you certainly know how to stimulate discussion. Cripes. 75 unread in mm-dev after a half-day. You all go, boys and girls. From donn@u.washington.edu Wed Jul 17 23:21:18 2002 From: donn@u.washington.edu (Donn Cave) Date: Wed, 17 Jul 2002 15:21:18 -0700 Subject: [Mailman-Developers] External domain web authentication Message-ID: <200207172221.g6HMLIeD002477@mailhost2.u.washington.edu> My site (University of Washington) has a central authentication domain, and we like to use it for everything. I have hacked up 2.1b2 to support external authentication, meaning that your site-wide (UW) login ID is attached to your Mailman email addresses, and once authenticated by our web login you're authorized to deal with those emails. We're getting set to use Mailman for a bunch of lists, like seriously several thousand. List membership varies, some are all UW (course mailing lists), some have hardly any UW members. Non-UW members will not be affected, they'll use the existing password system. UW members can use the password system too (so far, anyway), but they will normally (we hope) use their UW web login authentication. That's a cookie based central system, http://www.washington.edu/computing/pubcookie/ I process the potential UW login prior to WebAuthenticate(), and if it works, I can get per list email addresses for that ID, pick the right one for the page in question, if any, and authorize. Or if not, go on to WebAuthenticate() for the email and password. If authenticated by ID, I fill in the blanks in the listinfo page. I have it roughly working, can't tell if anyone but me has really even tried it yet. So it's real early in the development cycle. I can certainly release the code, but at this point it's more like a bunch of hacks to support our environment, than a solution to the general problem. Is there anyone else out there who is doing this kind of thing, or contemplating it? The changes are primarily in Cgi/*.py, plus a couple of policy refinements in MailList.py, and of course a module to handle all the new stuff and the external database that holds the list/email data for an ID. The database in particular is just a stop-gap implementation. Donn Cave, University Computing Services, University of Washington donn@u.washington.edu From jra@baylink.com Thu Jul 18 23:54:10 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Thu, 18 Jul 2002 18:54:10 -0400 Subject: [Mailman-Developers] Well, Chuq... In-Reply-To: <3D3727BA.5040808@west.sun.com>; from Dan Mick on Thu, Jul 18, 2002 at 01:40:26PM -0700 References: <3D3727BA.5040808@west.sun.com> Message-ID: <20020718185410.09902@scfn.thpl.lib.fl.us> On Thu, Jul 18, 2002 at 01:40:26PM -0700, Dan Mick wrote: > Cripes. 75 unread in mm-dev after a half-day. > You all go, boys and girls. My fault, not his. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From dmick@utopia.West.Sun.COM Fri Jul 19 00:37:19 2002 From: dmick@utopia.West.Sun.COM (Dan Mick) Date: Thu, 18 Jul 2002 16:37:19 -0700 (PDT) Subject: [Mailman-Developers] Well, Chuq... Message-ID: <200207182337.g6INbZOl027158@utopia.West.Sun.COM> > On Thu, Jul 18, 2002 at 01:40:26PM -0700, Dan Mick wrote: > > Cripes. 75 unread in mm-dev after a half-day. > > You all go, boys and girls. > > My fault, not his. "fault"? No fault implied. And I said "you all go" for a reason. ;) From claw@kanga.nu Fri Jul 19 01:53:59 2002 From: claw@kanga.nu (J C Lawrence) Date: Thu, 18 Jul 2002 17:53:59 -0700 Subject: [Mailman-Developers] Well, Chuq... In-Reply-To: Message from Dan Mick of "Thu, 18 Jul 2002 16:37:19 PDT." <200207182337.g6INbZOl027158@utopia.West.Sun.COM> References: <200207182337.g6INbZOl027158@utopia.West.Sun.COM> Message-ID: <26761.1027040039@kanga.nu> On Thu, 18 Jul 2002 16:37:19 -0700 (PDT) Dan Mick wrote: > And I said "you all go" for a reason. ;) Aye, there was value in that thread. -- 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 marc_news@merlins.org Thu Jul 18 23:15:42 2002 From: marc_news@merlins.org (Marc MERLIN) Date: Thu, 18 Jul 2002 15:15:42 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: References: <3D34BBC9.C0D8CB76@nleaudio.com> Message-ID: <20020718221542.GF4298@merlins.org> On Tue, Jul 16, 2002 at 05:28:07PM -0700, Chuq Von Rospach wrote: > Actually, the REAL state of the art is that they look up your MX records, > and do this to the HIGHEST ranked one (not the lowest). This is on the (it > turns out, quite valid) assumption that it won't be spamblocked as well as > the main MX relay is, but will be validated to forward stuff in to you. And > where they're trying that, we're finding it works (grumble grr) damn well. My secondary MXes are locked down even tighter for that exact reason, and you should use exim4 with the callout feature where you will not accept an rcpt to until after exim has down a callout from your secondary MX to your primary one. (if the primary one is actually down, then you do accept the mail) Of course, my secondary MXes do reject mail at SMTP time with SA-Exim :) Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From chuqui@plaidworks.com Fri Jul 19 16:47:26 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Fri, 19 Jul 2002 08:47:26 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <20020718221542.GF4298@merlins.org> Message-ID: On 7/18/02 3:15 PM, "Marc MERLIN" wrote: > On Tue, Jul 16, 2002 at 05:28:07PM -0700, Chuq Von Rospach wrote: >> Actually, the REAL state of the art is that they look up your MX records, >> and do this to the HIGHEST ranked one > My secondary MXes are locked down even tighter for that exact reason, One of the things I'm wondering is whether you could set up a trap up in the high MX records. You'd have to make sure your real mail system never failed badly enough to wander up there, but could you create problems by putting a tar baby up there? I wonder... -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ He doesn't have ulcers, but he's a carrier. From marc_news@merlins.org Fri Jul 19 17:17:18 2002 From: marc_news@merlins.org (Marc MERLIN) Date: Fri, 19 Jul 2002 09:17:18 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: References: <20020718221542.GF4298@merlins.org> Message-ID: <20020719161718.GB4367@merlins.org> On Fri, Jul 19, 2002 at 08:47:26AM -0700, Chuq Von Rospach wrote: > > My secondary MXes are locked down even tighter for that exact reason, > > One of the things I'm wondering is whether you could set up a trap up in the > high MX records. You'd have to make sure your real mail system never failed > badly enough to wander up there, but could you create problems by putting a > tar baby up there? I don't know if I would. I'm sure some legitimate MTAs and DNS servers would somehow sometimes end up with your highest MX. That said, I have indeed not tried it, it may virtually never happen. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From jra@baylink.com Fri Jul 19 16:52:28 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Fri, 19 Jul 2002 11:52:28 -0400 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: ; from Chuq Von Rospach on Fri, Jul 19, 2002 at 08:47:26AM -0700 References: <20020718221542.GF4298@merlins.org> Message-ID: <20020719115228.54202@scfn.thpl.lib.fl.us> On Fri, Jul 19, 2002 at 08:47:26AM -0700, Chuq Von Rospach wrote: > One of the things I'm wondering is whether you could set up a trap up in the > high MX records. You'd have to make sure your real mail system never failed > badly enough to wander up there, but could you create problems by putting a > tar baby up there? Ooooh.... that's diabolical. I like it. :-) Cheers, - jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From spacey-mailman@lenin.nu Fri Jul 19 17:57:26 2002 From: spacey-mailman@lenin.nu (Peter C. Norton) Date: Fri, 19 Jul 2002 09:57:26 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <20020719161718.GB4367@merlins.org> References: <20020718221542.GF4298@merlins.org> <20020719161718.GB4367@merlins.org> Message-ID: <20020719165726.GH15599@lenin.nu> On Fri, Jul 19, 2002 at 09:17:18AM -0700, Marc MERLIN wrote: > On Fri, Jul 19, 2002 at 08:47:26AM -0700, Chuq Von Rospach wrote: > > > My secondary MXes are locked down even tighter for that exact reason, > > > > One of the things I'm wondering is whether you could set up a trap up in the > > high MX records. You'd have to make sure your real mail system never failed > > badly enough to wander up there, but could you create problems by putting a > > tar baby up there? > > I don't know if I would. > I'm sure some legitimate MTAs and DNS servers would somehow sometimes end up > with your highest MX. > That said, I have indeed not tried it, it may virtually never happen. I wouldn't do it myself, but if you make 2 ip addresses on the same system with one higher pref and one lower pref, and ran the tarpit (or at least an information collector) on the the higher pref ip address, you may get a decent sample on whether or not your idea is going to interfere with your regular service. Since both are on the same system, nothing should ever contact the higher of the 2. -- The 5 year plan: In five years we'll make up another plan. Or just re-use this one. From chuqui@plaidworks.com Fri Jul 19 18:07:19 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Fri, 19 Jul 2002 10:07:19 -0700 Subject: [Mailman-Developers] Opening up a few can o' worms here... In-Reply-To: <20020719165726.GH15599@lenin.nu> Message-ID: On 7/19/02 9:57 AM, "Peter C. Norton" wrote: > I wouldn't do it myself, but if you make 2 ip addresses on the same > system with one higher pref and one lower pref, and ran the tarpit Yeah. I'm actually planning to do that once I finish up upgrading plaidworks.com to MacOS X, so I can do a port scanner sniffer, also. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ No! No! Dead girl, OFF the table! -- Shrek From terri@zone12.com Sat Jul 20 17:13:08 2002 From: terri@zone12.com (Terri Oda) Date: Sat, 20 Jul 2002 12:13:08 -0400 Subject: [Mailman-Developers] [MAILER-DAEMON@mira.linknet.com.au: Undeliverable Mail] Message-ID: <20020720161307.GA646@ostraya.zone12.com> I've been getting these periodically from one of my list members' servers and I'm curious... is To: user@domain.com really an invalid address? MailMAX is the only server I've ever seen thrown an error on this. I keep meaning to email them and ask what's up, since it seems like a bug to me, but before I do, does anyone know if this is actually an invalid address and other servers just deal with it? ----- Forwarded message from MailMAX Error Responder ----- Delivery-date: Sat, 20 Jul 2002 11:45:31 -0400 From: "MailMAX Error Responder" Subject: Undeliverable Mail When we said... DATA .. the remote server gave us this error response ... 550 Syntax error in 'To' header: malformed address: \n may not follow courses@linuxchix.org : failing address is: courses@linuxchix.org This is a Permanent error, and we will not try to deliver it again. *** This message was automatically generated by the MailMAX Error Responder *** From jra@baylink.com Sat Jul 20 17:12:09 2002 From: jra@baylink.com (Jay R. Ashworth) Date: Sat, 20 Jul 2002 12:12:09 -0400 Subject: [Mailman-Developers] [MAILER-DAEMON@mira.linknet.com.au: Undeliverable Mail] In-Reply-To: <20020720161307.GA646@ostraya.zone12.com>; from Terri Oda on Sat, Jul 20, 2002 at 12:13:08PM -0400 References: <20020720161307.GA646@ostraya.zone12.com> Message-ID: <20020720121209.03315@scfn.thpl.lib.fl.us> On Sat, Jul 20, 2002 at 12:13:08PM -0400, Terri Oda wrote: > I've been getting these periodically from one of my list members' servers > and I'm curious... is > To: user@domain.com > really an invalid address? MailMAX is the only server I've ever seen thrown > an error on this. > > I keep meaning to email them and ask what's up, since it seems like a bug to > me, but before I do, does anyone know if this is actually an invalid address > and other servers just deal with it? According to my reading of RFC 2822 3.4, no, it's fine: if a mailbox can be a name-addr, and a name-addr is a display-name followed by an angle-addr, then the display-name should be treated as a comment by any mailre, provided that the angle-addr is syntactically correctly constructed. But this is more properly a topic for comp.mail.headers. (Does that NG still exist? ;-) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") From alan@batie.org Sat Jul 20 18:05:09 2002 From: alan@batie.org (Alan Batie) Date: Sat, 20 Jul 2002 10:05:09 -0700 Subject: [Mailman-Developers] [MAILER-DAEMON@mira.linknet.com.au: Undeliverable Mail] In-Reply-To: <20020720161307.GA646@ostraya.zone12.com> References: <20020720161307.GA646@ostraya.zone12.com> Message-ID: <20020720100509.A13735@agora.rdrop.com> On Sat, Jul 20, 2002 at 12:13:08PM -0400, Terri Oda wrote: > I've been getting these periodically from one of my list members' servers > and I'm curious... is > To: user@domain.com > really an invalid address? MailMAX is the only server I've ever seen thrown > an error on this. I thought it was legal, but on reviewing RFC 822, I find that it is, in fact, invalid: if the phrase outside <>'s contains any of spaces, ctrls or: specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- / "," / ";" / ":" / "\" / <"> ; string, to use / "." / "[" / "]" ; within a word. ...it must be quoted: To: "user@domain.com" -- Alan Batie ______ www.rdrop.com/users/alan Me alan@batie.org \ / www.qrd.org The Triangle PGPFP DE 3C 29 17 C0 49 7A \ / www.pgpi.com The Weird Numbers 27 40 A5 3C 37 4A DA 52 B9 \/ razor.sourceforge.net NO SPAM! A free society is a place where it's safe to be unpopular. -Adlai Stevenson, statesman (1900-1965) From dan@dankohn.com Sat Jul 20 20:21:23 2002 From: dan@dankohn.com (Dan Kohn) Date: Sat, 20 Jul 2002 12:21:23 -0700 Subject: [Mailman-Developers] [MAILER-DAEMON@mira.linknet.com.au:Undeliverable Mail] Message-ID: RFC 822 has been obsoleted by RFC 2822. See my next message for more details. http://www.normos.org/en/summaries/ietf/rfc/rfc822.html - dan -- Dan Kohn -----Original Message----- From: Alan Batie [mailto:alan@batie.org]=20 Sent: Saturday, July 20, 2002 10:05 To: Terri Oda Cc: mailman-developers@python.org Subject: Re: [Mailman-Developers] [MAILER-DAEMON@mira.linknet.com.au:Undeliverable Mail] On Sat, Jul 20, 2002 at 12:13:08PM -0400, Terri Oda wrote: > I've been getting these periodically from one of my list members' servers > and I'm curious... is=20 > To: user@domain.com =20 > really an invalid address? MailMAX is the only server I've ever seen thrown > an error on this. =20 I thought it was legal, but on reviewing RFC 822, I find that it is, in fact, invalid: if the phrase outside <>'s contains any of spaces, ctrls or: specials =3D "(" / ")" / "<" / ">" / "@" ; Must be in quoted- / "," / ";" / ":" / "\" / <"> ; string, to use / "." / "[" / "]" ; within a word. ...it must be quoted: To: "user@domain.com" --=20 Alan Batie ______ www.rdrop.com/users/alan Me alan@batie.org \ / www.qrd.org The Triangle PGPFP DE 3C 29 17 C0 49 7A \ / www.pgpi.com The Weird Numbers 27 40 A5 3C 37 4A DA 52 B9 \/ razor.sourceforge.net NO SPAM! A free society is a place where it's safe to be unpopular. -Adlai Stevenson, statesman (1900-1965) _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman-21/listinfo/mailman-developers From dan@dankohn.com Sat Jul 20 20:39:22 2002 From: dan@dankohn.com (Dan Kohn) Date: Sat, 20 Jul 2002 12:39:22 -0700 Subject: [Mailman-Developers] [MAILER-DAEMON@mira.linknet.com.au:Undeliverable Mail] Message-ID: "user@domain.com " is not legal under RFC 2822. It is must not generate under either current (section 3) or obsolete (section 4) grammar. is defined as "[display-name] angle-addr", is a , which is "1*word", where is "atom / quoted-string". is defined in section 3.2.4 *not* to include "@". In other words, you can't use an unquoted "@" in a under either current or obsolete grammar. However, you could include the @ as part of a , defined in section 3.2.5. Thus, the following: user@domain.com <-- illegal "user\@domain.com" <-- legal I'm cc'ing ietf-822@imc.org, which has taken the place of comp.mail.headers, for confirmation. - dan -- Dan Kohn -----Original Message----- From: Jay R. Ashworth [mailto:jra@baylink.com]=20 Sent: Saturday, July 20, 2002 09:12 To: mailman-developers@python.org Subject: Re: [Mailman-Developers] [MAILER-DAEMON@mira.linknet.com.au:Undeliverable Mail] On Sat, Jul 20, 2002 at 12:13:08PM -0400, Terri Oda wrote: > I've been getting these periodically from one of my list members' servers > and I'm curious... is=20 > To: user@domain.com =20 > really an invalid address? MailMAX is the only server I've ever seen thrown > an error on this. =20 >=20 > I keep meaning to email them and ask what's up, since it seems like a bug to > me, but before I do, does anyone know if this is actually an invalid address > and other servers just deal with it? According to my reading of RFC 2822 3.4, no, it's fine: if a mailbox can be a name-addr, and a name-addr is a display-name followed by an angle-addr, then the display-name should be treated as a comment by any mailre, provided that the angle-addr is syntactically correctly constructed. But this is more properly a topic for comp.mail.headers. (Does that NG still exist? ;-) Cheers, -- jra --=20 Jay R. Ashworth jra@baylink.com Member of the Technical Staff Baylink RFC 2100 The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274 "If you don't have a dream; how're you gonna have a dream come true?" -- Captain Sensible, The Damned (from South Pacific's "Happy Talk") _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman-21/listinfo/mailman-developers From noreply@sourceforge.net Sun Jul 21 13:32:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 21 Jul 2002 05:32:58 -0700 Subject: [Mailman-Developers] [ mailman-Feature Requests-584468 ] listinfo: cache Message-ID: Feature Requests item #584468, was opened at 2002-07-21 14:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=584468&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) Summary: listinfo: cache Initial Comment: We`re running more than 700 lists on our mailinglist-server. Mailman needs between 20 and 40 seconds to generate the public listinfo page. Wouldn`t it be possible to generate a listinfo.cache including all these necessary informations to speed up the process? These listinfo.cache could be valid for some specific time, before it is removed and regenerated. Or this cache-file can be deleted if somenbody is changing his list configuration. Thanks... p.heinlein@jpberlin.de ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=584468&group_id=103 From noreply@sourceforge.net Mon Jul 22 08:57:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jul 2002 00:57:02 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-584775 ] long listnames in RFC2369 breake header! Message-ID: Bugs item #584775, was opened at 2002-07-22 09:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584775&group_id=103 Category: mail delivery Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) Summary: long listnames in RFC2369 breake header! Initial Comment: We have some lists with very long listnames. If I include RDC2369-headers they're breaking up the header and suddenly they`re part of the mailbody. It seems, that CookHeaders.py adds a line break or an empty line or something like that and the MTA (Postfix) takes this empty line as the split between header and beginning body. Peer ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584775&group_id=103 From noreply@sourceforge.net Mon Jul 22 08:57:44 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jul 2002 00:57:44 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-584775 ] long listnames in RFC2369 break header! Message-ID: Bugs item #584775, was opened at 2002-07-22 09:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584775&group_id=103 Category: mail delivery Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) >Summary: long listnames in RFC2369 break header! Initial Comment: We have some lists with very long listnames. If I include RDC2369-headers they're breaking up the header and suddenly they`re part of the mailbody. It seems, that CookHeaders.py adds a line break or an empty line or something like that and the MTA (Postfix) takes this empty line as the split between header and beginning body. Peer ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584775&group_id=103 From noreply@sourceforge.net Mon Jul 22 15:09:36 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jul 2002 07:09:36 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-584917 ] Extra slash in private archive URL Message-ID: Bugs item #584917, was opened at 2002-07-22 07:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584917&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Arnett (narnett) Assigned to: Nobody/Anonymous (nobody) Summary: Extra slash in private archive URL Initial Comment: Mailman 2.0 on RH 7.1 -- After converting a public archive to private and rebuilding with bin/arch, the web pages pointing to the private archive have an extra slash in them (after /private/). E.g.: http://www.mccmedia.com/mailman/private//myli st/ I haven't tried to reproduce this yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584917&group_id=103 From noreply@sourceforge.net Mon Jul 22 17:09:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jul 2002 09:09:11 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-584775 ] long listnames in RFC2369 break header! Message-ID: Bugs item #584775, was opened at 2002-07-22 09:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584775&group_id=103 Category: mail delivery Group: 2.1 beta >Status: Closed Resolution: None >Priority: 6 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) Summary: long listnames in RFC2369 break header! Initial Comment: We have some lists with very long listnames. If I include RDC2369-headers they're breaking up the header and suddenly they`re part of the mailbody. It seems, that CookHeaders.py adds a line break or an empty line or something like that and the MTA (Postfix) takes this empty line as the split between header and beginning body. Peer ---------------------------------------------------------------------- >Comment By: Peer Heinlein (pheinlein) Date: 2002-07-22 18:09 Message: Logged In: YES user_id=581680 Sorry, it seems that this bug is already fixed in snapshot 20020722. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584775&group_id=103 From noreply@sourceforge.net Mon Jul 22 17:15:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jul 2002 09:15:13 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-584989 ] bounced large messages are deleted! Message-ID: Bugs item #584989, was opened at 2002-07-22 18:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584989&group_id=103 Category: mail delivery Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) Summary: bounced large messages are deleted! Initial Comment: I`m using 2.1b2+ (July, 22th) and if a message is larger than the maximum allowd size (of this list) it is not bounced or hold for approval succesfully. The message disappears and mailman crashes. Maybe it`s just a mistake in the translation in german mailman.po? Jul 22 17:36:55 2002 (28610) Uncaught runner exception: an integer is required Jul 22 17:36:55 2002 (28610) Traceback (most recent call last): File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 154, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 129, in _dispose status = self._dopipeline(mlist, msg, msgdata, pipeline) File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 152, in _dopipel sys.modules[modname].process(mlist, msg, msgdata) File "/usr/lib/mailman/Mailman/Handlers/Hold.py", line 179, in process MessageTooBig(bodylen, mlist.max_message_size)) File "/usr/lib/mailman/Mailman/Handlers/Hold.py", line 198, in hold_for_approv reason = Utils.wrap(exc.reason_notice()) File "/usr/lib/mailman/Mailman/Handlers/Hold.py", line 103, in reason_notice return _('''Message body is too big: %(size)d bytes with a limit of File "/usr/lib/mailman/Mailman/i18n.py", line 76, in _ return _translation.gettext(s) % dict TypeError: an integer is required ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584989&group_id=103 From wheakory@isu.edu Mon Jul 22 20:07:36 2002 From: wheakory@isu.edu (Kory Wheatley) Date: Mon, 22 Jul 2002 13:07:36 -0600 Subject: [Mailman-Developers] Mailman 2.0.12 error Message-ID: <3D3C57F8.3AA430B5@isu.edu> I keep receiving this error when messages are sent to my lists. I'm running Red Hat 7.2 mailman 2.0.12. Does anyone know the solution? Jul 20 12:02:00 2002 qrunner(18056): Traceback (innermost last): Jul 20 12:02:00 2002 qrunner(18056): File "/home/mailman/cron/qrunner", line 283, in ? Jul 20 12:02:00 2002 qrunner(18056): kids = main(lock) Jul 20 12:02:00 2002 qrunner(18056): File "/home/mailman/cron/qrunner", line 253, in main Jul 20 12:02:00 2002 qrunner(18056): keepqueued = dispose_message(mlist, msg, msgdata) Jul 20 12:02:00 2002 qrunner(18056): File "/home/mailman/cron/qrunner", line 157, in dispose_message Jul 20 12:02:00 2002 qrunner(18056): mlist.ParseMailCommands(msg) Jul 20 12:02:00 2002 qrunner(18056): File "/home/mailman/Mailman/MailCommandHandler.py", line 123, in ParseMailCommands Jul 20 12:02:00 2002 qrunner(18056): precedence = msg.get('precedence', '').lower() Jul 20 12:02:00 2002 qrunner(18056): AttributeError : 'string' object has no attribute 'lower' Jul 20 12:03:00 2002 qrunner(18059): Traceback (innermost last): Jul 20 12:03:00 2002 qrunner(18059): File "/home/mailman/cron/qrunner", line 283, in ? Jul 20 12:03:00 2002 qrunner(18059): kids = main(lock) Jul 20 12:03:00 2002 qrunner(18059): File "/home/mailman/cron/qrunner", line 253, in main Jul 20 12:03:00 2002 qrunner(18059): keepqueued = dispose_message(mlist, msg, msgdata) Jul 20 12:03:00 2002 qrunner(18059): File "/home/mailman/cron/qrunner", line 157, in dispose_message Jul 20 12:03:00 2002 qrunner(18059): mlist.ParseMailCommands(msg) Jul 20 12:03:00 2002 qrunner(18059): File "/home/mailman/Mailman/MailCommandHandler.py", line 123, in ParseMailCommands Jul 20 12:03:00 2002 qrunner(18059): precedence = msg.get('precedence', '').lower() Jul 20 12:03:00 2002 qrunner(18059): AttributeError : 'string' object has no attribute 'lower' Jul 20 12:04:06 2002 qrunner(18066): Traceback (innermost last): Kory Wheatley From mrbill@mrbill.net Mon Jul 22 21:01:45 2002 From: mrbill@mrbill.net (Bill Bradford) Date: Mon, 22 Jul 2002 15:01:45 -0500 Subject: [Mailman-Developers] Problem with 2.0.12 configure Message-ID: <20020722200145.GC16538@mrbill.net> root@ohno:/usr/local/src/mailman-2.0.12> sh ./configure --prefix=/usr/local/mailman loading cache ./config.cache checking for --with-python... no checking for python... /usr/local/bin/python checking Python interpreter... /usr/local/bin/python checking Python version... 2.2.1c1 checking for a BSD compatible install... /usr/local/bin/install -c checking whether make sets ${MAKE}... yes checking for true... /usr/bin/true checking for --without-gcc... no checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking whether #! works in shell scripts... yes checking for --with-var-prefix... no checking for --with-username... mailman checking for mailman UID... 10004 checking for --with-groupname... mailman checking for mailman GID... 10004 checking permissions on /usr/local/mailman... okay checking for mail wrapper GID... 1 checking for CGI wrapper GID... 60001 checking for CGI extensions... no ./configure: test: unknown operator == Same result with sh or bash. Any suggestions? Nothing relevant in config.log.. Tracing the script, this is what I get: # attempt to figure out the default hostname and URL from socket import * import string import sys import os def barf(fqdn, www): sys.stdout = sys.stderr print 'host info not found, set \$MAILHOST and/or \$WWWHOST environ vars' print '\$MAILHOST=%s, \$WWWHOST=%s' % (fqdn, www) sys.exit(1) fqdn = os.environ.get('MAILHOST') www = os.environ.get('WWWHOST') aliases = [] if fqdn: aliases.append(fqdn) if www: aliases.append(www) if not fqdn: try: host, aliases, ipaddrs = gethostbyaddr(gethostbyname(gethostname())) except herror: barf(fqdn, www) aliases.insert(0, host) for h in aliases: parts = string.split(h, '.') if 5 > 1: if parts[0] == 'www': www = h elif not fqdn: fqdn = h if www and fqdn: break if fqdn is None: barf(fqdn, www) if www is None: www = fqdn fp = open('conftest.out', 'w') if not www and fqdn: fp.write('%s\n%s\n' % (fqdn, fqdn)) elif www: dhn = string.join(string.split(www, '.')[1:], '.') fp.write('%s\n%s\n' % (dhn, www)) else: fp.write('please.change.me\nwww.please.change.me\n') fp.close() EOF $PYTHON conftest.py if [ "$?" == "1" ] then exit fi ./configure: test: unknown operator == Bill -- bill bradford / mrbill@mrbill.net / austin, texas ------------------------------------------------------------------------- I'm reminded of the day my daughter came in, looked over my shoulder at some Perl 4 code, and said, "What is that, swearing?" -- Larry Wall From laurence@digitalpulp.com Mon Jul 22 22:05:24 2002 From: laurence@digitalpulp.com (Laurence Berland) Date: Mon, 22 Jul 2002 17:05:24 -0400 Subject: [Mailman-Developers] Modifying mailman to filter archived messages In-Reply-To: <15669.54908.141903.520297@anthem.wooz.org> References: <200207151634.51587.laurence@digitalpulp.com> <15669.54908.141903.520297@anthem.wooz.org> Message-ID: <200207221705.24883.laurence@digitalpulp.com> On Wednesday 17 July 2002 04:41 pm, Barry A. Warsaw wrote: > >>>>> "LB" =3D=3D Laurence Berland writes: > ... > from Mailman.Handlers import OurStatusMunger > ... > if getattr(mlist, 'munge_status_p', 0): > =09OurStatusMunger.process(mlist, msg, msgdata) > ... > I'm mostly following this, but am having a little trouble at the point wh= ere I=20 write the process function. Looking at other handlers I've determined I = can=20 get a header by msg.gtheader(header-name-string) and get the body by=20 msg.body. I've also determined you can alter headers by setting=20 msg[header-name-string] but what I haven't figured out it what I can do t= o=20 set the body to something. The idea is to apply a regular expression on = the=20 body of the message. Thanks again for all the help, Laurence From noreply@sourceforge.net Tue Jul 23 04:03:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 22 Jul 2002 20:03:21 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-585229 ] opening holes by changing permissions? Message-ID: Bugs item #585229, was opened at 2002-07-22 22:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585229&group_id=103 Category: configuring/installing Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Paul Marshall (paulmarshll) Assigned to: Nobody/Anonymous (nobody) Summary: opening holes by changing permissions? Initial Comment: I was having problems adding a list in Mailman 2.1beta via the web interface, it was giving me an error regarding permissions to the mailman/data/aliases.db file. This is the error I got: ... File "/var/mailman/Mailman/MTA/Postfix.py", line 46, in _update_maps raise RuntimeError, msg % (acmd, status, errstr) RuntimeError: command failed: /usr/sbin/postalias /var/mailman/data/aliases (status: 1, Operation not permitted) To fix this I changed the permissions on this file so apache could write to it. chmod a+w aliases.db This did fix the problem of creating and deleting lists via the web interface. Does anyone know if this would open up any security holes? Is there another way to fix the permissions problem that is more logical? Thanks for your help. Paul Marshall ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585229&group_id=103 From chris@in-berlin.de Sun Jul 21 15:24:46 2002 From: chris@in-berlin.de (Christian Seitz) Date: Sun, 21 Jul 2002 16:24:46 +0200 (CEST) Subject: [Mailman-Developers] patch: reply-to list and sender Message-ID: Hi all, we moved our mailing lists from Majordomo to Mailman several months ago and one disadvantage of Mailman is, that you can set the reply-to only to "Poster", "This list" and "Explicit address", but not to something like "This list and sender". This patch is testet with Mailman 2.0.6 to 2.0.11 and it works fine for us. Could you please include this patch in the next version of Mailman? --- mailman-2.0.11/Mailman/MailList.py Sun Jul 21 15:51:06 2002 +++ mailman-2.0.11-patched/Mailman/MailList.py Sun Jul 21 15:51:10 2002 @@ -420,7 +420,7 @@ ' text will be added to the unsubscribe message.'), ('reply_goes_to_list', mm_cfg.Radio, - ('Poster', 'This list', 'Explicit address'), 0, + ('Poster', 'This list', 'Explicit address', 'This list and sender'), 0, '''Where are replies to list messages directed? Poster is strongly recommended for most mailing lists.''', --- mailman-2.0.11/Mailman/Handlers/CookHeaders.py Sun Jul 21 15:51:44 2002 +++ mailman-2.0.11-patched/Mailman/Handlers/CookHeaders.py Sun Jul 21 15:51:41 2002 @@ -89,7 +89,11 @@ elif mlist.reply_goes_to_list == 2: xreplyto = msg.get('reply-to') msg['Reply-To'] = mlist.reply_to_address - # Give the recipient some ability to un-munge things. + # Set Reply-To: to list and sender + elif mlist.reply_goes_to_list == 3: + xreplyto = msg.get('reply-to') + msg['Reply-To'] = mlist.GetListEmail() + ', ' + msg.GetSender() + # Give the recipient some ability to un-munge things. if xreplyto: msg['X-Reply-To'] = xreplyto # Chris -- Christian Seitz http://berli.net/ IN-Berlin - http://www.in-berlin.de/ PGP Fingerprint: A9 17 03 0D 36 AB 07 4E D0 1E C3 8E 3F B0 66 9A From dman@dman.ddts.net Tue Jul 23 07:29:26 2002 From: dman@dman.ddts.net (Derrick 'dman' Hudson) Date: Tue, 23 Jul 2002 01:29:26 -0500 Subject: [Mailman-Developers] Re: [MAILER-DAEMON@mira.linknet.com.au: Undeliverable Mail] In-Reply-To: <20020720161307.GA646@ostraya.zone12.com> References: <20020720161307.GA646@ostraya.zone12.com> Message-ID: <20020723062925.GA19607@dman.ddts.net> ---------------------- multipart/signed attachment On Sat, Jul 20, 2002 at 12:13:08PM -0400, Terri Oda wrote: | I've been getting these periodically from one of my list members' servers | and I'm curious... is=20 | To: user@domain.com =20 | really an invalid address? As others have said, no. | MailMAX is the only server I've ever seen thrown an error on this. =20 Try it against my exim server. I've enabled its syntax checking which causes it to reject messages like that. (it also rejects a good number of spam messages with bogus headers) -D --=20 > SELECT * FROM users WHERE clue > 0 0 rows returned (http://www.thinkgeek.com/images/products/zoom/no-clue.= jpg) =20 http://dman.ddts.net/~dman/ ---------------------- multipart/signed attachment A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 240 bytes Desc: not available Url : http://mail.python.org/pipermail-21/mailman-developers/attachments/0e7f345b/attachment.bin ---------------------- multipart/signed attachment-- From dwing@cisco.com Sun Jul 21 02:44:33 2002 From: dwing@cisco.com (Dan Wing) Date: Sat, 20 Jul 2002 18:44:33 -0700 Subject: [Mailman-Developers] [MAILER-DAEMON@mira.linknet.com.au:Undeliverable Mail] In-Reply-To: <200207202038.g6KKcCt28124@astro.cs.utk.edu> Message-ID: > perhaps even worse, it's redundant. why say > > user@domain.com > > or even > > "user@domain.com" > > when simply > > user@domain.com > > will do? Because in Microsoft's Outlook and Outlook Express, if a user is in your addressbook and you send a message to that user, only their friendly name ("Keith Moore") appears in the "To:" line. You must click your mouse on the name to see the user@host form of the name. The workaround is to put moore@cs.utk.edu in the friendly name field so that moore@cs.utk.edu displays in the "To:" line, which is a more natural address for email for many, many people. > a phrase containing another copy of the address conveys no additional > information, it just wastes bandwidth and invites stupid mail handling tools > to play with it. -d From moore@cs.utk.edu Sat Jul 20 21:38:12 2002 From: moore@cs.utk.edu (Keith Moore) Date: Sat, 20 Jul 2002 16:38:12 -0400 Subject: [Mailman-Developers] [MAILER-DAEMON@mira.linknet.com.au:Undeliverable Mail] In-Reply-To: (Your message of "Sat, 20 Jul 2002 12:39:22 PDT.") Message-ID: <200207202038.g6KKcCt28124@astro.cs.utk.edu> > "user@domain.com " is not legal under RFC 2822. It is > must not generate under either current (section 3) or obsolete (section > 4) grammar. true, it's illegal to have an '@' in a phrase unless its quoted. it was illegal in RFC 822 also, which means it's been illegal for 20 years or so. an '@' can't appear in an atom. perhaps even worse, it's redundant. why say user@domain.com or even "user@domain.com" when simply user@domain.com will do? a phrase containing another copy of the address conveys no additional information, it just wastes bandwidth and invites stupid mail handling tools to play with it. Keith From moore@cs.utk.edu Sun Jul 21 06:07:48 2002 From: moore@cs.utk.edu (Keith Moore) Date: Sun, 21 Jul 2002 01:07:48 -0400 Subject: [Mailman-Developers] [MAILER-DAEMON@mira.linknet.com.au:Undeliverable Mail] In-Reply-To: (Your message of "Sat, 20 Jul 2002 18:44:33 PDT.") Message-ID: <200207210507.g6L57mt29245@astro.cs.utk.edu> > Because in Microsoft's Outlook and Outlook Express, if a > user is in your addressbook and you send a message to that > user, only their friendly name ("Keith Moore") appears in > the "To:" line. You must click your mouse on the name to > see the user@host form of the name. The workaround is > to put moore@cs.utk.edu in the friendly name field so > that moore@cs.utk.edu displays in the "To:" line, which > is a more natural address for email for many, many > people. so those who use Microsoft products lose. what else is new? Keith From noreply@sourceforge.net Tue Jul 23 08:05:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jul 2002 00:05:14 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-585270 ] qrunner fails with RHL7.2 python 1.5.2 Message-ID: Bugs item #585270, was opened at 2002-07-23 17:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585270&group_id=103 Category: mail delivery Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Stuart Prescott (themill) Assigned to: Nobody/Anonymous (nobody) Summary: qrunner fails with RHL7.2 python 1.5.2 Initial Comment: qrunner from mailman-2.0.12 (downloaded and installed from the src tarball) fails with Python 1.5.2 from RHL7.2 python-1.5.2-38. Error message from $prefix/logs/error is attached as is a patch that does seem to fix the problem and allow Mailman to work. (I'm not a Python programmer .. I noramlly use P**L so I'm not sure exactly what or why... please treat my patch with the greatest skepticism!) >From the mailing lists, there are quite a few ppl having problems with the RHL distributions of Python -- is this a compatability thing (that we can argue about whether it's RHL or Mailman that is at fault a la gcc for years to come?) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585270&group_id=103 From dag@sonsorol.org Tue Jul 23 16:18:13 2002 From: dag@sonsorol.org (Chris Dagdigian) Date: Tue, 23 Jul 2002 11:18:13 -0400 Subject: [Mailman-Developers] problems with mailman 2.0.12 qrunner failing to process any messages Message-ID: <3D3D73B5.4090006@sonsorol.org> Hi folks, First off thanks for making such a great package. I've been using mailman for a few years now to run mailing lists for various open source informatics efforts like biojava.org, biopython.org and bioperl.org. We upgraded to 2.0.12 over the weekend and are now having trouble with mailman. It's basically stopped processing incoming email. From looking at google and various mailing man list archives it seems that my problem is very similar to what some people saw in v2.06 with mailman not being able to gracefully handle some error or bounce situations. The patches discussed however seem to be already in place with mailman 2.0.12 (specifically a change to Boucers/DSN.py). Right now I'm manually moving .msg and .db files into and out of the qfiles directory so that I can at least get some mail out. This will hopefully also give me a small sample of "bad" emails that are triggering the problem. I'm not a python person so I'd appreciate any tips on how to resolve this. Here are the specifics: qrunner is bombing out with an error and leaving lots of unprocessed messages in the qfiles/ directory. The output from the 'error' logfile is as follows: [mailman@pw600a ~/qfiles]$ tail ../logs/error Jul 23 11:10:01 2002 qrunner(8882): Traceback (innermost last): Jul 23 11:10:01 2002 qrunner(8882): File "/home/mailman/cron/qrunner", line 283, in ? Jul 23 11:10:01 2002 qrunner(8882): kids = main(lock) Jul 23 11:10:01 2002 qrunner(8882): File "/home/mailman/cron/qrunner", line 253, in main Jul 23 11:10:01 2002 qrunner(8882): keepqueued = dispose_message(mlist, msg, msgdata) Jul 23 11:10:01 2002 qrunner(8882): File "/home/mailman/cron/qrunner", line 157, in dispose_message Jul 23 11:10:01 2002 qrunner(8882): mlist.ParseMailCommands(msg) Jul 23 11:10:01 2002 qrunner(8882): File "/home/mailman/Mailman/MailCommandHandler.py", line 123, in ParseMailCommands Jul 23 11:10:01 2002 qrunner(8882): precedence = msg.get('precedence', '').lower() Jul 23 11:10:01 2002 qrunner(8882): AttributeError : 'string' object has no attribute 'lower Regards, Chris -- Chris Dagdigian, Independent life science IT & research computing consulting Office: 617-666-6454, Mobile: 617-877-5498, Fax: 425-699-0193 Work: http://BioTeam.net PGP KeyID: 83D4310E Yahoo IM: craffi From laurence@digitalpulp.com Tue Jul 23 16:43:43 2002 From: laurence@digitalpulp.com (Laurence Berland) Date: Tue, 23 Jul 2002 11:43:43 -0400 Subject: [Mailman-Developers] Modifying mailman to filter archived messages In-Reply-To: <15669.54908.141903.520297@anthem.wooz.org> References: <200207151634.51587.laurence@digitalpulp.com> <15669.54908.141903.520297@anthem.wooz.org> Message-ID: <200207231143.43407.laurence@digitalpulp.com> On Wednesday 17 July 2002 04:41 pm, Barry A. Warsaw wrote: > A general approach would be to hack into the > Mailman/Queue/ArchRunner.py file, ArchRunner._dispose() method. I'd > write a separate "handler module", say > Mailman/Handlers/OurStatusMunger.py which does the specifics of the > transformation you're interested in. Although your situation is > fairly unique, you might want to copy the API and style of other > handler modules in that directory. I'm using mailman 2.0.11 and can't seem to find the file ArchRunner.py, o= r=20 even a Queue directory for that matter. Is this because my version is to= o=20 old/new? Where would I find this in 2.0.11, or should I just upgrade and= =20 port the work I've already done over? If so, what version should I upgra= de=20 to, keeping in mind this code needs to actually be used in production in = the=20 near future, so beta (2.1?) isn't necessarily a good idea. > > Then add something to _dispose() that checks an attribute on the mlist > object to decide whether to call into your handler module. I'd do the > check like this: > > ... > from Mailman.Handlers import OurStatusMunger > ... > if getattr(mlist, 'munge_status_p', 0): > =09OurStatusMunger.process(mlist, msg, msgdata) > ... > > and then use bin/withlist to add this attribute (set to 1 of course!) > to just the list you want to do the extra processing on. I've added a few config flags instead. When I finish with all this, is t= here=20 any interest in adding it back in to the mailman source? It offers three= =20 configurable parameters for archives. Regex filtering on/off, regex patt= ern,=20 replacement pattern. I can think of a few interesting uses offhand, name= ly=20 variable spam armoring, automatic filtering of obscenity (if it's a list = for=20 children or something, I don't want to claim to generally advocate that s= ort=20 of thing), gratuitous substitution of phrases (I know some people who'd l= ove=20 to always replace "Microsoft" with "the evil whose name one dares not spe= ak"=20 in every message...), etc. > > Note that if you want to do this /before/ the message hits the > archiver, e.g. you want it in the outgoing messages, you'd simply need > to add the OurStatusMunger module to the GLOBAL_PIPELINE variable in > Defaults.py.in -- another good reason to make OurStatusMunger.py > conform to the handler API. > I'm trying to conform, and hopefully someone will be willing to glance ov= er=20 stuff when I'm done and tell me if I have conformed sufficiently, and if = not=20 what changes I need make. Thanks again for the extensive help, Laurence From noreply@sourceforge.net Tue Jul 23 17:32:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jul 2002 09:32:39 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-585484 ] virtual domain lists misdirect autoreply Message-ID: Bugs item #585484, was opened at 2002-07-23 16:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585484&group_id=103 Category: bounce detection Group: None Status: Open Resolution: None Priority: 5 Submitted By: Byron T. Watts (btwatts) Assigned to: Nobody/Anonymous (nobody) Summary: virtual domain lists misdirect autoreply Initial Comment: Using mailman with virtual domain hosting. Bounced messages for a particular list are going to the wrong list administrator (not even on the same domain). The particular notices that I'm seeing misdirected, are the useridi> is on vacation messages. I am not certain whether other messages are being similarly misdirected. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585484&group_id=103 From barry@zope.com Tue Jul 23 18:01:30 2002 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 23 Jul 2002 13:01:30 -0400 Subject: [Mailman-Developers] ASCII Prefixes Message-ID: <15677.35818.738471.340987@anthem.wooz.org> Here's a tricky issue, one with a high rabbit hole probability (which I'd like to avoid if possible ;). Say you've got a mailing list that accepts both French and English, with French as the default language. The default charset for French is iso-8859-1 and for English us-ascii. Now say you want to add a prefix to your list, say "[MyList]", and you're users like to send messages to the list with funny non-ascii characters in iso-8859-1. What Mailman 2.1 cvs will do now is encode the prefix using the charset for the list's default language. So you'd likely end up with a Subject: header like Subject: =?iso-8859-1?q?[MyList]_?= =?iso-8859-1?hello_world?= or some such. Encoding the prefix can be considered ugly, but unfortunately we don't really have a way to specify a charset for the subject prefix (or footers, or other added text) apart from the default language's charset. So this is /almost/ the best we can do, even though it's kind of ugly. OTOH, we could use a simple heuristic to try to keep the prefix unencoded in the common case: if the prefix contains only ascii characters, we could choose to leave it in the default us-ascii (or really the None) encoding. If it contains non-ascii characters, we'd have no choice but to encode it. I really don't want to go down the path of providing a gui for different prefixes for each supported language. Eventually, maybe that's what we need to do, but I'd like to avoid that for MM2.1. I think this approach should be good enough, but I'd like to hear comments, especially from Asian language users. -Barry From wheakory@isu.edu Tue Jul 23 18:07:42 2002 From: wheakory@isu.edu (Kory Wheatley) Date: Tue, 23 Jul 2002 11:07:42 -0600 Subject: [Mailman-Developers] Mailman 2.0.12 error Message-ID: <3D3D8D5E.8000708@isu.edu> This is very critical I get this fixed, I'm running 150 production mailing lists, here's my problem. I keep receiving this below error when messages are sent to my lists. I'm running Red Hat 7.2 mailman 2.0.12. Does anyone know the solution? If I take them out of the qfiles directory and then put a few in at a time then the messages are sent rather than piling up in the qfiles directory and setting there idle. I've had this problem the day after I upgraded to mailman 2.0.12 from mailman 2.0.11, is there a patch fix. qrunner(18056): Traceback (innermost last): qrunner(18056): File "/home/mailman/cron/qrunner", line 283, in ? "/home/mailman/cron/qrunner", line 283, in ? qrunner(18056): kids = main(lock) qrunner(18056): File "/home/mailman/cron/qrunner", line 253, in main qrunner(18056): keepqueued = dispose_message(mlist, msg, msgdata) qrunner(18056): File "/home/mailman/cron/qrunner", line 157, in dispose_message qrunner(18056): mlist.ParseMailCommands(msg) qrunner(18056): File "/home/mailman/Mailman/MailCommandHandler.py", line 123, in ParseMailCommands qrunner(18056): precedence = msg.get('precedence', '').lower() qrunner(18056): AttributeError : 'string' object has no attribute 'lower' qrunner(18059): Traceback (innermost last): qrunner(18059): File "/home/mailman/cron/qrunner", line 283, in ? qrunner(18059): kids = main(lock) qrunner(18059): File "/home/mailman/cron/qrunner", line 253, in main qrunner(18059): keepqueued = dispose_message(mlist, msg, msgdata) qrunner(18059): File "/home/mailman/cron/qrunner", line 157, in dispose_message qrunner(18059): mlist.ParseMailCommands(msg) qrunner(18059): File "/home/mailman/Mailman/MailCommandHandler.py", line 123, in ParseMailCommands qrunner(18059): precedence = msg.get('precedence', '').lower() qrunner(18059): AttributeError : 'string' object has no attribute 'lower' qrunner(18066): Traceback (innermost last): -- ######################################### Kory Wheatley Academic Computing Analyst Sr. Phone 282-3874 ######################################### Everything must point to him. From barry@python.org Tue Jul 23 18:17:49 2002 From: barry@python.org (Barry A. Warsaw) Date: Tue, 23 Jul 2002 13:17:49 -0400 Subject: [Mailman-Developers] ASCII Prefixes References: <15677.35818.738471.340987@anthem.wooz.org> Message-ID: <15677.36797.71769.365936@anthem.wooz.org> >>>>> "BAW" =3D=3D Barry A Warsaw writes: BAW> OTOH, we could use a simple heuristic to try to keep the BAW> prefix unencoded in the common case: if the prefix contains BAW> only ascii characters, we could choose to leave it in the BAW> default us-ascii (or really the None) encoding. If it BAW> contains non-ascii characters, we'd have no choice but to BAW> encode it. I just realized there's one unfortunate side effect of this choice. As Ben is fond of pointing out, the RFCs are vague at what should happen to spaces between non-encoded text and encoded words. It isn't specified whether that whitespace is significant (as in unencoded text) or ignored (as inbetween encoded words). So this Subject: line Subject: [Foo] =3D?iso-8859-1?Q?accentu=3DE9_that_n?=3D =3D?iso-885= 9-1?Q?eeds_m=3DF4re_sp=3DE0ces?=3D may be displayed in your MUA as Subject: [Foo] accentu=E9 that needs m=F4re sp=E0ces or Subject: [Foo]accentu=E9 that needs m=F4re sp=E0ces I'm not sure what to do about that. -Barry From barry@python.org Tue Jul 23 18:19:46 2002 From: barry@python.org (Barry A. Warsaw) Date: Tue, 23 Jul 2002 13:19:46 -0400 Subject: [Mailman-Developers] Mailman 2.0.12 error References: <3D3D8D5E.8000708@isu.edu> Message-ID: <15677.36914.471864.937888@anthem.wooz.org> >>>>> "KW" == Kory Wheatley writes: KW> This is very critical I get this fixed, I'm running 150 KW> production mailing lists, here's my problem. Apply the following patch. Mailman 2.0.12 had compatibility issues with Python 1.5.2. Later today I will post a candidate patch for 2.0.13 to fix this and one or two other small issues. -Barry -------------------- snip snip -------------------- Index: MailCommandHandler.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Attic/MailCommandHandler.py,v retrieving revision 1.70.2.1 retrieving revision 1.70.2.2 diff -u -r1.70.2.1 -r1.70.2.2 --- MailCommandHandler.py 2 Jul 2002 16:33:23 -0000 1.70.2.1 +++ MailCommandHandler.py 11 Jul 2002 21:19:34 -0000 1.70.2.2 @@ -120,8 +120,8 @@ # of these clues, so there's little we can do to break loops in that # case, except throttle the number of responses sent to any one # requester in a day. That's a job for MM2.1. - precedence = msg.get('precedence', '').lower() - ack = msg.get('x-ack', '').lower() + precedence = string.lower(msg.get('precedence', '')) + ack = string.lower(msg.get('x-ack', '')) beenthere = msg.get('x-beenthere', '') listid = msg.get('list-id', '') if (precedence in ('bulk', 'list', 'junk') or From dag@sonsorol.org Tue Jul 23 18:44:48 2002 From: dag@sonsorol.org (Chris Dagdigian) Date: Tue, 23 Jul 2002 13:44:48 -0400 Subject: [Mailman-Developers] Re: problems with mailman 2.0.12 qrunner failing to process any messages References: <3D3D73B5.4090006@sonsorol.org> Message-ID: <3D3D9610.8060400@sonsorol.org> Following up on my own email to continue the thread.... After isolating 14 messages and moving them out of the qfiles/ directory I was able to manually run qrunner and get my 412+ delayed mailing list messages. The process basically involved: (1) manually running qmail until it fails (2) move the offending .msg and .db file out of qfiles/ (3) manually run qmail until it fails (4) move the offending .msg and .sb file out of qfiles/ (5) repeat cycle until qfiles/ is empty The most interesting thing that I've learned is that almost all of the messages (.msg and .db) files that I had to manually move out of the qfiles directory are actually email replies from people using the subscription-confirmation process. I'm going to wait until mail traffic dies down on the server and will then experiment to confirm that the Mailman confirmation email replies are causing qrunner to fail with a python traceback. -Chris > > [mailman@pw600a ~/qfiles]$ tail ../logs/error > Jul 23 11:10:01 2002 qrunner(8882): Traceback (innermost last): > Jul 23 11:10:01 2002 qrunner(8882): File "/home/mailman/cron/qrunner", > line 283, in ? > Jul 23 11:10:01 2002 qrunner(8882): kids = main(lock) > Jul 23 11:10:01 2002 qrunner(8882): File "/home/mailman/cron/qrunner", > line 253, in main > Jul 23 11:10:01 2002 qrunner(8882): keepqueued = > dispose_message(mlist, msg, msgdata) > Jul 23 11:10:01 2002 qrunner(8882): File "/home/mailman/cron/qrunner", > line 157, in dispose_message > Jul 23 11:10:01 2002 qrunner(8882): mlist.ParseMailCommands(msg) > Jul 23 11:10:01 2002 qrunner(8882): File > "/home/mailman/Mailman/MailCommandHandler.py", line 123, in > ParseMailCommands > Jul 23 11:10:01 2002 qrunner(8882): precedence = > msg.get('precedence', '').lower() > Jul 23 11:10:01 2002 qrunner(8882): AttributeError : 'string' object > has no attribute 'lower From terri@zone12.com Tue Jul 23 19:32:43 2002 From: terri@zone12.com (Terri Oda) Date: Tue, 23 Jul 2002 14:32:43 -0400 Subject: [Mailman-Developers] [MAILER-DAEMON@mira.linknet.com.au:Undeliverable Mail] In-Reply-To: References: <200207202038.g6KKcCt28124@astro.cs.utk.edu> Message-ID: <20020723183243.GA457@ostraya.zone12.com> > Because in Microsoft's Outlook and Outlook Express, if a > user is in your addressbook and you send a message to that > user, only their friendly name ("Keith Moore") appears in > the "To:" line. You must click your mouse on the name to > see the user@host form of the name. The workaround is > to put moore@cs.utk.edu in the friendly name field so > that moore@cs.utk.edu displays in the "To:" line, which > is a more natural address for email for many, many > people. Actually, the offending client in this case is Sylpheed, much as I'd like to blame outlook. (goodness knows, I blame it for Klez.) I'd have to find someone with a copy of outlook to try it and be sure, but I think outlook does "user@domain.com" which probably wouldn't have been a problem. Terri From moore@cs.utk.edu Tue Jul 23 21:37:33 2002 From: moore@cs.utk.edu (Keith Moore) Date: Tue, 23 Jul 2002 16:37:33 -0400 Subject: [Mailman-Developers] [MAILER-DAEMON@mira.linknet.com.au:Undeliverable Mail] In-Reply-To: (Your message of "Tue, 23 Jul 2002 14:32:43 EDT.") <20020723183243.GA457@ostraya.zone12.com> Message-ID: <200207232037.g6NKbXt16714@astro.cs.utk.edu> > Actually, the offending client in this case is Sylpheed, much as I'd like to > blame outlook. (goodness knows, I blame it for Klez.) I take it Sylpheed is the one that generates bogus phrases? > I'd have to find someone with a copy of outlook to try it and be sure, but I > think outlook does "user@domain.com" which probably > wouldn't have been a problem. it might be syntactically legal, but it's still utterly stupid. Keith From laurence@digitalpulp.com Tue Jul 23 22:06:31 2002 From: laurence@digitalpulp.com (Laurence Berland) Date: Tue, 23 Jul 2002 17:06:31 -0400 Subject: [Mailman-Developers] 2.1b2-production ready? Message-ID: <200207231706.31857.laurence@digitalpulp.com> How unready for production use is 2.1b2? I've written a Handler module f= or=20 mailman, that I wanted to use to filter things coming into the archive, b= ut I=20 can't find where to put the call to the handler in 2.0. I don't want it = in=20 the pipeline because it should only act on the archived messages, not the= =20 ones sent out. Any hints on where this should go? How far away is a 2.1= =20 release? TIA, Laurence From dan@dankohn.com Tue Jul 23 23:39:04 2002 From: dan@dankohn.com (Dan Kohn) Date: Tue, 23 Jul 2002 15:39:04 -0700 Subject: [Mailman-Developers] [MAILER-DAEMON@mira.linknet.com.au:Undeliverable Mail] Message-ID: FYI, Outlook with Exchange Server 2000, does the "right thing". Here's the To lines on an outgoing message: From: "Dan Kohn" To: Cc: - dan -- Dan Kohn -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu]=20 Sent: Tuesday, July 23, 2002 13:38 To: Terri Oda Cc: Dan Wing; Keith Moore; Dan Kohn; Jay R. Ashworth; mailman-developers@python.org; ietf-822@imc.org Subject: Re: [Mailman-Developers] [MAILER-DAEMON@mira.linknet.com.au:Undeliverable Mail]=20 > Actually, the offending client in this case is Sylpheed, much as I'd like to > blame outlook. (goodness knows, I blame it for Klez.) I take it Sylpheed is the one that generates bogus phrases? =20 > I'd have to find someone with a copy of outlook to try it and be sure, but I > think outlook does "user@domain.com" which probably > wouldn't have been a problem. it might be syntactically legal, but it's still utterly stupid. Keith From noreply@sourceforge.net Tue Jul 23 23:51:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jul 2002 15:51:50 -0700 Subject: [Mailman-Developers] [ mailman-Patches-585643 ] Mailman 2.0.13 candidate patch Message-ID: Patches item #585643, was opened at 2002-07-23 18:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=585643&group_id=103 Category: None Group: Mailman 2.0.x Status: Open Resolution: None Priority: 8 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Mailman 2.0.13 candidate patch Initial Comment: Mailman 2.0.12 had compatibility problems with Python 1.5.2. This patch fixes these AFAICT, and a few other small bugs that have cropped up. Note that this is a candidate patch. The actual MM2.0.13 patch may be different. However I would really appreciate folks using Mailman 2.0.12 (especially if you're using Python 1.5.2) to give this patch a try and see if it fixes your problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=585643&group_id=103 From barry@zope.com Wed Jul 24 05:14:12 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 24 Jul 2002 00:14:12 -0400 Subject: [Mailman-Developers] Candidate Mailman 2.0.13 patch Message-ID: <15678.10644.858948.973667@anthem.wooz.org> As some of you have noticed, Mailman 2.0.12 has some compatibility problems with Python 1.5.2. In order to correct this, and a few other minor problems, I want to soon release a version 2.0.13. This time, however I'd like to enlist your help. ;) I have uploaded a candidate patch for 2.0.12 -> 2.0.13 at this url: http://sf.net/tracker/index.php?func=detail&aid=585643&group_id=103&atid=300103 I would appreciate it if someone (or a few someones) could give this patch a try. I'm essentially running it on python.org/zope.org, however I'm using Python 2.1.3 in my production environment. I have done some limited testing with Python 1.5.2 and this patch and it seems to go okay. I'd especially like to hear from those of you experiencing problems with MailCommandHandler, if you are running MM2.0.12 with Python 1.5.2. Does this patch fix things for you? Does it produce any other tracebacks or warnings in logs/error? Thanks for any feedback you can provide. If I get some positive feedback (or at least, no negative feedback) in a few days, I'd do a formal release. I expect that to be largely similar to this patch, with perhaps some documentation updates, unless other problems are uncovered by your testing. Thanks! -Barry From barry@zope.com Wed Jul 24 05:36:20 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 24 Jul 2002 00:36:20 -0400 Subject: [Mailman-Developers] ASCII Prefixes References: <15677.35818.738471.340987@anthem.wooz.org> <3D3D9ADF.3070103@debian.org> Message-ID: <15678.11972.251673.330524@anthem.wooz.org> >>>>> "BG" == Ben Gertzfield writes: >> Here's a tricky issue, one with a high rabbit hole probability >> (which I'd like to avoid if possible ;). OTOH, we could use a >> simple heuristic to try to keep the prefix unencoded in the >> common case: if the prefix contains only ascii characters, we >> could choose to leave it in the default us-ascii (or really the >> None) encoding. If it contains non-ascii characters, we'd have >> no choice but to encode it. BG> OTOOH, we could make *this* the per-list setting; we could BG> have the heuristic guess whether to encode or not if the list BG> owner wants it. That way we don't have to have a ton of prefix BG> character set settings, and we make the people who get angry BG> at seeing [MyFrenchList] encoded in header QP happy. Is subject_prefix the only place this option would make sense? If so, then I can probably add a boolean variable to the General admin page, otherwise I might want to add something to the Languages page. BG> Sorry for being absent recently, I'm finally at a job that's BG> challenging enough to make my brain not want to do coding at BG> home. :) That's good (I think ;). Welcome back, and I hope you'll stick around! -Barry From barry@python.org Wed Jul 24 05:38:47 2002 From: barry@python.org (Barry A. Warsaw) Date: Wed, 24 Jul 2002 00:38:47 -0400 Subject: [Mailman-Developers] Problem with 2.0.12 configure References: <20020722200145.GC16538@mrbill.net> Message-ID: <15678.12119.592584.384309@anthem.wooz.org> >>>>> "BB" == Bill Bradford writes: | ./configure: test: unknown operator == This is another thing fixed in the MM 2.0.13 candidate patch. -Barry From barry@python.org Wed Jul 24 05:40:02 2002 From: barry@python.org (Barry A. Warsaw) Date: Wed, 24 Jul 2002 00:40:02 -0400 Subject: [Mailman-Developers] problems with mailman 2.0.12 qrunner failing toprocess any messages References: <3D3D73B5.4090006@sonsorol.org> Message-ID: <15678.12194.63109.765977@anthem.wooz.org> >>>>> "CD" == Chris Dagdigian writes: CD> We upgraded to 2.0.12 over the weekend and are now having CD> trouble with mailman. It's basically stopped processing CD> incoming email. CD> From looking at google and various mailing man list archives CD> it seems that my problem is very similar to what some people CD> saw in v2.06 with mailman not being able to gracefully handle CD> some error or bounce situations. The patches discussed however CD> seem to be already in place with mailman 2.0.12 (specifically CD> a change to Boucers/DSN.py). CD> Right now I'm manually moving .msg and .db files into and out CD> of the qfiles directory so that I can at least get some mail CD> out. This will hopefully also give me a small sample of "bad" CD> emails that are triggering the problem. CD> I'm not a python person so I'd appreciate any tips on how to CD> resolve this. Here are the specifics: You're likely using Python 1.5.2. This is exactly the incompatibility fixed in the MM 2.0.13 candidate patch. -Barry From barry@python.org Wed Jul 24 05:43:19 2002 From: barry@python.org (Barry A. Warsaw) Date: Wed, 24 Jul 2002 00:43:19 -0400 Subject: [Mailman-Developers] 2.1b2-production ready? References: <200207231706.31857.laurence@digitalpulp.com> Message-ID: <15678.12391.192915.737145@anthem.wooz.org> >>>>> "LB" == Laurence Berland writes: LB> How unready for production use is 2.1b2? I've written a LB> Handler module for mailman, that I wanted to use to filter LB> things coming into the archive, but I can't find where to put LB> the call to the handler in 2.0. I don't want it in the LB> pipeline because it should only act on the archived messages, LB> not the ones sent out. Any hints on where this should go? LB> How far away is a 2.1 release? We're using 2.1cvs in production on python.org (for this list in fact), so it's stable enough. There are still a few rough edges here and there, but I'm watching it closely and trying to keep it patch. I will likely release another beta sometime this week or by the weekend. At that point I'll feel good enough about it to migrate the rest of the mailman-* lists over to it. -Barry From barry@zope.com Wed Jul 24 05:48:06 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 24 Jul 2002 00:48:06 -0400 Subject: [Mailman-Developers] Modifying mailman to filter archived messages References: <200207151634.51587.laurence@digitalpulp.com> <15669.54908.141903.520297@anthem.wooz.org> <200207221705.24883.laurence@digitalpulp.com> Message-ID: <15678.12678.484954.506211@anthem.wooz.org> >>>>> "LB" == Laurence Berland writes: >> ... from Mailman.Handlers import OurStatusMunger ... if >> getattr(mlist, 'munge_status_p', 0): >> OurStatusMunger.process(mlist, msg, msgdata) >> ... >> LB> I'm mostly following this, but am having a little trouble at LB> the point where I write the process function. Looking at LB> other handlers I've determined I can get a header by LB> msg.gtheader(header-name-string) and get the body by msg.body. LB> I've also determined you can alter headers by setting LB> msg[header-name-string] but what I haven't figured out it what LB> I can do to set the body to something. The idea is to apply a LB> regular expression on the body of the message. Ouch, if you're using MM2.0.x then it gets pretty painful to do these kinds of message manipulation. Any chance you can be coaxed into using MM2.1? There, you've got the email package at your disposal, so modifying message headers and payloads (email package parlance for message bodies), is much more regular and predictable. E.g. you'd do msg.get(fieldname) to get the contents of a header, and "del msg[fieldname] ; msg[fieldname] = value" to replace the contents of a header. msg.attach(attachment) or msg.set_payload(body) to manipulate the body of a message, etc. The Python 2.2 documentation is helpful for the basics of the email package, however it has undergone significant extension and API improvements. The documentation has not yet caught up, so you should use the source for the most up-to-date information. -Barry From che@debian.org Wed Jul 24 05:51:52 2002 From: che@debian.org (Ben Gertzfield) Date: Tue, 23 Jul 2002 21:51:52 -0700 Subject: [Mailman-Developers] ASCII Prefixes In-Reply-To: <15678.11972.251673.330524@anthem.wooz.org> Message-ID: <12412B5D-9EC1-11D6-ABC8-0003931E4DBC@debian.org> On Tuesday, July 23, 2002, at 09:36 , Barry A. Warsaw wrote: > BG> OTOOH, we could make *this* the per-list setting; we could > BG> have the heuristic guess whether to encode or not if the list > BG> owner wants it. That way we don't have to have a ton of prefix > BG> character set settings, and we make the people who get angry > BG> at seeing [MyFrenchList] encoded in header QP happy. > > Is subject_prefix the only place this option would make sense? If so, > then I can probably add a boolean variable to the General admin page, > otherwise I might want to add something to the Languages page. The only other place I could guess would be the message headers and footers. But bodies are so commonly encoded in quoted-printable these days that it's pretty much not an issue. I'll guess the only reason people have an issue with headers having encoded-words that don't "need to" be encoded is because there are a few people out there who don't have RFC-compliant mail readers. Ben From barry@zope.com Wed Jul 24 05:52:50 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 24 Jul 2002 00:52:50 -0400 Subject: [Mailman-Developers] Modifying mailman to filter archived messages References: <200207151634.51587.laurence@digitalpulp.com> <15669.54908.141903.520297@anthem.wooz.org> <200207231143.43407.laurence@digitalpulp.com> Message-ID: <15678.12962.668844.226703@anthem.wooz.org> >>>>> "LB" == Laurence Berland writes: LB> I'm using mailman 2.0.11 and can't seem to find the file LB> ArchRunner.py, or even a Queue directory for that matter. Is LB> this because my version is too old/new? Too old. MM2.0.x is in the critical patch only phase of its life, and even that is getting difficult to do correctly (witness the 2.0.12 problem w/ Python 1.5.2). LB> Where would I find this in 2.0.11, or should I just upgrade LB> and port the work I've already done over? If so, what version LB> should I upgrade to, keeping in mind this code needs to LB> actually be used in production in the near future, so beta LB> (2.1?) isn't necessarily a good idea. Depends. MM2.1 is probably the only one that has the architecture you'll need to do the things I think you'll want to do. It's mostly stable enough. LB> I've added a few config flags instead. When I finish with all LB> this, is there any interest in adding it back in to the LB> mailman source? It offers three configurable parameters for LB> archives. Regex filtering on/off, regex pattern, replacement LB> pattern. I can think of a few interesting uses offhand, LB> namely variable spam armoring, automatic filtering of LB> obscenity (if it's a list for children or something, I don't LB> want to claim to generally advocate that sort of thing), LB> gratuitous substitution of phrases (I know some people who'd LB> love to always replace "Microsoft" with "the evil whose name LB> one dares not speak" in every message...), etc. Possibly, but MM2.1 is pretty well feature frozen. LB> I'm trying to conform, and hopefully someone will be willing LB> to glance over stuff when I'm done and tell me if I have LB> conformed sufficiently, and if not what changes I need make. The best approach, IMO is to post your work as a patch to the SF patch managers, and announce it here so folks can take a look. -Barry From noreply@sourceforge.net Wed Jul 24 06:06:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jul 2002 22:06:21 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-584989 ] bounced large messages are deleted! Message-ID: Bugs item #584989, was opened at 2002-07-22 12:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584989&group_id=103 Category: mail delivery Group: 2.1 beta >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) Summary: bounced large messages are deleted! Initial Comment: I`m using 2.1b2+ (July, 22th) and if a message is larger than the maximum allowd size (of this list) it is not bounced or hold for approval succesfully. The message disappears and mailman crashes. Maybe it`s just a mistake in the translation in german mailman.po? Jul 22 17:36:55 2002 (28610) Uncaught runner exception: an integer is required Jul 22 17:36:55 2002 (28610) Traceback (most recent call last): File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 154, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 129, in _dispose status = self._dopipeline(mlist, msg, msgdata, pipeline) File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 152, in _dopipel sys.modules[modname].process(mlist, msg, msgdata) File "/usr/lib/mailman/Mailman/Handlers/Hold.py", line 179, in process MessageTooBig(bodylen, mlist.max_message_size)) File "/usr/lib/mailman/Mailman/Handlers/Hold.py", line 198, in hold_for_approv reason = Utils.wrap(exc.reason_notice()) File "/usr/lib/mailman/Mailman/Handlers/Hold.py", line 103, in reason_notice return _('''Message body is too big: %(size)d bytes with a limit of File "/usr/lib/mailman/Mailman/i18n.py", line 76, in _ return _translation.gettext(s) % dict TypeError: an integer is required ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 01:06 Message: Logged In: YES user_id=12800 It does look like it's a bug in the German translation for that message. I'm about to commit a fix to the German catalog; can you try doing a cvs update and see if that fixes your problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584989&group_id=103 From noreply@sourceforge.net Wed Jul 24 06:08:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jul 2002 22:08:31 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-584917 ] Extra slash in private archive URL Message-ID: Bugs item #584917, was opened at 2002-07-22 10:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584917&group_id=103 Category: None >Group: 2.0.x >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Nick Arnett (narnett) Assigned to: Nobody/Anonymous (nobody) Summary: Extra slash in private archive URL Initial Comment: Mailman 2.0 on RH 7.1 -- After converting a public archive to private and rebuilding with bin/arch, the web pages pointing to the private archive have an extra slash in them (after /private/). E.g.: http://www.mccmedia.com/mailman/private//myli st/ I haven't tried to reproduce this yet. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 01:08 Message: Logged In: YES user_id=12800 Check the value for PRIVATE_ARCHIVE_URL in your mm_cfg.py file. I'll be it ends in a slash. It shouldn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584917&group_id=103 From dwing@cisco.com Wed Jul 24 06:22:37 2002 From: dwing@cisco.com (Dan Wing) Date: Tue, 23 Jul 2002 22:22:37 -0700 Subject: [Mailman-Developers] [MAILER-DAEMON@mira.linknet.com.au:Undeliverable Mail] In-Reply-To: Message-ID: Send us a screen shot of what your To line looked like, though. -d > -----Original Message----- > From: Dan Kohn [mailto:dan@dankohn.com] > Sent: Tuesday, July 23, 2002 3:39 PM > To: Keith Moore; Terri Oda > Cc: Dan Wing; Jay R. Ashworth; mailman-developers@python.org; > ietf-822@imc.org > Subject: RE: [Mailman-Developers] > [MAILER-DAEMON@mira.linknet.com.au:Undeliverable Mail] > > > FYI, Outlook with Exchange Server 2000, does the "right thing". Here's > the To lines on an outgoing message: > > From: "Dan Kohn" > To: > Cc: > > - dan > -- > Dan Kohn > > > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Tuesday, July 23, 2002 13:38 > To: Terri Oda > Cc: Dan Wing; Keith Moore; Dan Kohn; Jay R. Ashworth; > mailman-developers@python.org; ietf-822@imc.org > Subject: Re: [Mailman-Developers] > [MAILER-DAEMON@mira.linknet.com.au:Undeliverable Mail] > > > > Actually, the offending client in this case is Sylpheed, much as I'd > like to > > blame outlook. (goodness knows, I blame it for Klez.) > > I take it Sylpheed is the one that generates bogus phrases? > > > I'd have to find someone with a copy of outlook to try it and be sure, > but I > > think outlook does "user@domain.com" which probably > > wouldn't have been a problem. > > it might be syntactically legal, but it's still utterly stupid. > > Keith > From noreply@sourceforge.net Wed Jul 24 06:25:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 23 Jul 2002 22:25:43 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-584917 ] Extra slash in private archive URL Message-ID: Bugs item #584917, was opened at 2002-07-22 07:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584917&group_id=103 Category: None Group: 2.0.x Status: Closed Resolution: Works For Me >Priority: 2 Submitted By: Nick Arnett (narnett) Assigned to: Nobody/Anonymous (nobody) Summary: Extra slash in private archive URL Initial Comment: Mailman 2.0 on RH 7.1 -- After converting a public archive to private and rebuilding with bin/arch, the web pages pointing to the private archive have an extra slash in them (after /private/). E.g.: http://www.mccmedia.com/mailman/private//myli st/ I haven't tried to reproduce this yet. ---------------------------------------------------------------------- >Comment By: Nick Arnett (narnett) Date: 2002-07-23 22:25 Message: Logged In: YES user_id=390959 The value for PRIVATE_ARCHIVE_URL was the problem... but I don't think this bug should be closed until the file is modified to include a comment to that effect, or the code modified to allow a trailing slash. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-23 22:08 Message: Logged In: YES user_id=12800 Check the value for PRIVATE_ARCHIVE_URL in your mm_cfg.py file. I'll be it ends in a slash. It shouldn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584917&group_id=103 From Daniel.Buchmann@bibsys.no Wed Jul 24 08:14:26 2002 From: Daniel.Buchmann@bibsys.no (Daniel Buchmann) Date: 24 Jul 2002 09:14:26 +0200 Subject: [Mailman-Developers] 2.1b2-production ready? In-Reply-To: <15678.12391.192915.737145@anthem.wooz.org> References: <200207231706.31857.laurence@digitalpulp.com> <15678.12391.192915.737145@anthem.wooz.org> Message-ID: <1027493378.2277.20.camel@fornax.bibsys.no> ---------------------- multipart/signed attachment On Wed, 2002-07-24 at 06:43, Barry A. Warsaw wrote: >=20 > We're using 2.1cvs in production on python.org (for this list in > fact), so it's stable enough. There are still a few rough edges here > and there, but I'm watching it closely and trying to keep it patch. I'm also using 2.1cvs in production, and it works fine! It has, as you say, a few rough edges here and there yes.. ;) An example: one of my boxes has 19 messages in qfiles/shunt... I also have a bunch of errors in logs/error... :-/ They are mostly "ValueError: year out of range" errors (see bug #571634). I also have a few "AlreadyLockedError"s: Jul 24 04:06:57 2002 (3897) Traceback (most recent call last): File "/home/mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/home/mailman/Mailman/Queue/Runner.py", line 154, in __onefile keepqueued =3D self._dispose(mlist, msg, msgdata) File "/home/mailman/Mailman/Queue/ArchRunner.py", line 34, in _dispose mlist.Lock(timeout=3Dmm_cfg.LIST_LOCK_TIMEOUT) File "/home/mailman/Mailman/MailList.py", line 143, in Lock self.__lock.lock(timeout) File "/home/mailman/Mailman/LockFile.py", line 284, in lock raise AlreadyLockedError AlreadyLockedError And a couple of web tracebacks, too lengthy to dump here, let me know if you want 'em. ;) > I will likely release another beta sometime this week or by the > weekend. At that point I'll feel good enough about it to migrate the > rest of the mailman-* lists over to it. Ok, would be nice if you could weed through the bug reports on SF.net and maybe fix some of them before you release a new beta, though.. (Which would probably give me time to catch up on the norwegian translation... ;) -Daniel ---------------------- multipart/signed attachment A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: This is a digitally signed message part Url : http://mail.python.org/pipermail-21/mailman-developers/attachments/bc70bee4/attachment.bin ---------------------- multipart/signed attachment-- From noreply@sourceforge.net Wed Jul 24 09:14:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jul 2002 01:14:13 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-584989 ] bounced large messages are deleted! Message-ID: Bugs item #584989, was opened at 2002-07-22 18:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584989&group_id=103 Category: mail delivery Group: 2.1 beta Status: Closed Resolution: Fixed Priority: 5 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) Summary: bounced large messages are deleted! Initial Comment: I`m using 2.1b2+ (July, 22th) and if a message is larger than the maximum allowd size (of this list) it is not bounced or hold for approval succesfully. The message disappears and mailman crashes. Maybe it`s just a mistake in the translation in german mailman.po? Jul 22 17:36:55 2002 (28610) Uncaught runner exception: an integer is required Jul 22 17:36:55 2002 (28610) Traceback (most recent call last): File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 154, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 129, in _dispose status = self._dopipeline(mlist, msg, msgdata, pipeline) File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 152, in _dopipel sys.modules[modname].process(mlist, msg, msgdata) File "/usr/lib/mailman/Mailman/Handlers/Hold.py", line 179, in process MessageTooBig(bodylen, mlist.max_message_size)) File "/usr/lib/mailman/Mailman/Handlers/Hold.py", line 198, in hold_for_approv reason = Utils.wrap(exc.reason_notice()) File "/usr/lib/mailman/Mailman/Handlers/Hold.py", line 103, in reason_notice return _('''Message body is too big: %(size)d bytes with a limit of File "/usr/lib/mailman/Mailman/i18n.py", line 76, in _ return _translation.gettext(s) % dict TypeError: an integer is required ---------------------------------------------------------------------- >Comment By: Peer Heinlein (pheinlein) Date: 2002-07-24 10:14 Message: Logged In: YES user_id=581680 It looks like it works. -Thanks! But now I`m getting the message "`import site` failed; use -v to traceback"?! Peer ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 07:06 Message: Logged In: YES user_id=12800 It does look like it's a bug in the German translation for that message. I'm about to commit a fix to the German catalog; can you try doing a cvs update and see if that fixes your problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584989&group_id=103 From noreply@sourceforge.net Wed Jul 24 09:17:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jul 2002 01:17:59 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-585776 ] no webauthentification possible Message-ID: Bugs item #585776, was opened at 2002-07-24 10:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585776&group_id=103 Category: Web/CGI Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) Summary: no webauthentification possible Initial Comment: After updating to 2.1b some of our lists aren`t accessible for admins any more. I`m using the current cvs, but when they try to login mailman crashes: Traceback (most recent call last): File "/usr/lib/mailman/scripts/driver", line 82, in run_main main() File "/usr/lib/mailman/Mailman/Cgi/admin.py", line 82, in main cgidata.getvalue('adminpw', '')): File "/usr/lib/mailman/Mailman/SecurityManager.py", line 206, in WebAuthenticate ac = self.Authenticate(authcontexts, response, user) File "/usr/lib/mailman/Mailman/SecurityManager.py", line 159, in Authenticate elif crypt and crypt.crypt(response, secret[:2]) == secret: TypeError: argument 2 must be string without null bytes, not str ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585776&group_id=103 From noreply@sourceforge.net Wed Jul 24 11:22:28 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jul 2002 03:22:28 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-585833 ] Forward posts held for approval Message-ID: Bugs item #585833, was opened at 2002-07-24 10:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585833&group_id=103 Category: mail delivery Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Ousmane Wilane (wilane) Assigned to: Nobody/Anonymous (nobody) Summary: Forward posts held for approval Initial Comment: FWIW I'm using the current cvs. When I forward a mail which was held for approval to my email address (oversized mail in this case) I get the provided traceback in my logs and the mail in shunt q: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585833&group_id=103 From dag@sonsorol.org Wed Jul 24 12:46:18 2002 From: dag@sonsorol.org (Chris Dagdigian) Date: Wed, 24 Jul 2002 07:46:18 -0400 Subject: [Mailman-Developers] problems with mailman 2.0.12 qrunner failing to process any messages References: <3D3D73B5.4090006@sonsorol.org> <15678.12194.63109.765977@anthem.wooz.org> Message-ID: <3D3E938A.9090006@sonsorol.org> Last night I patched my 2.0.12 distribution with the patch shown in this email: http://mail.python.org/pipermail-21/mailman-developers/2002-July/012476.html It worked wonderfully -- all mail including the ones that caused qrunner to stop have all been processed fine. No errors at all in the logs as of this morning. So- consider this at least 1 success story for python1.5.2 and MM2.0.12. Much appreciated! Chris Barry A. Warsaw wrote: > > You're likely using Python 1.5.2. This is exactly the incompatibility > fixed in the MM 2.0.13 candidate patch. > > -Barry -- Chris Dagdigian, Independent life science IT & research computing consulting Office: 617-666-6454, Mobile: 617-877-5498, Fax: 425-699-0193 Work: http://BioTeam.net PGP KeyID: 83D4310E Yahoo IM: craffi From philb@philb.us Wed Jul 24 13:02:48 2002 From: philb@philb.us (Phil Barnett) Date: Wed, 24 Jul 2002 08:02:48 -0400 Subject: [Mailman-Developers] Modifying mailman to filter archived messages In-Reply-To: <15678.12962.668844.226703@anthem.wooz.org> References: <200207151634.51587.laurence@digitalpulp.com> <200207231143.43407.laurence@digitalpulp.com> <15678.12962.668844.226703@anthem.wooz.org> Message-ID: <200207240802.48125.philb@philb.us> On Wednesday 24 July 2002 00:52, Barry A. Warsaw wrote: > Too old. MM2.0.x is in the critical patch only phase of its life, and > even that is getting difficult to do correctly (witness the 2.0.12 > problem w/ Python 1.5.2). =20 Has there been an official release of 2.1? From noreply@sourceforge.net Wed Jul 24 14:03:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jul 2002 06:03:09 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-584917 ] Extra slash in private archive URL Message-ID: Bugs item #584917, was opened at 2002-07-22 10:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584917&group_id=103 Category: None Group: 2.0.x Status: Closed Resolution: Works For Me Priority: 2 Submitted By: Nick Arnett (narnett) Assigned to: Nobody/Anonymous (nobody) Summary: Extra slash in private archive URL Initial Comment: Mailman 2.0 on RH 7.1 -- After converting a public archive to private and rebuilding with bin/arch, the web pages pointing to the private archive have an extra slash in them (after /private/). E.g.: http://www.mccmedia.com/mailman/private//myli st/ I haven't tried to reproduce this yet. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 09:03 Message: Logged In: YES user_id=12800 I've added a line of comment to the Defaults.py.in file for MM 2.0.13. ---------------------------------------------------------------------- Comment By: Nick Arnett (narnett) Date: 2002-07-24 01:25 Message: Logged In: YES user_id=390959 The value for PRIVATE_ARCHIVE_URL was the problem... but I don't think this bug should be closed until the file is modified to include a comment to that effect, or the code modified to allow a trailing slash. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 01:08 Message: Logged In: YES user_id=12800 Check the value for PRIVATE_ARCHIVE_URL in your mm_cfg.py file. I'll be it ends in a slash. It shouldn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584917&group_id=103 From stsimb@irc.gr Wed Jul 24 08:27:53 2002 From: stsimb@irc.gr (Sotiris Tsimbonis) Date: Wed, 24 Jul 2002 10:27:53 +0300 (EEST) Subject: [Mailman-Developers] Re: [Mailman-Announce] Candidate Mailman 2.0.13 patch In-Reply-To: <15678.10644.858948.973667@anthem.wooz.org> Message-ID: On Wed, 24 Jul 2002, Barry A. Warsaw wrote: > As some of you have noticed, Mailman 2.0.12 has some compatibility > problems with Python 1.5.2. [...] > I'd especially like to hear from those of you experiencing problems > with MailCommandHandler, if you are running MM2.0.12 with Python > 1.5.2. Does this patch fix things for you? Does it produce any other > tracebacks or warnings in logs/error? Hi! I am running Mailman 2.0.12 with Python 1.5.2 on a linux box, and had problems with torequests.. with this candidate patch they seem to be fixed, as all messages in the queue have now been processed and the queue is clear :-) Thanks for the good work you've been doing all this time :-) Best regards, Sot. From vanhorn@whidbey.com Wed Jul 24 08:41:04 2002 From: vanhorn@whidbey.com (G. Armour Van Horn) Date: Wed, 24 Jul 2002 00:41:04 -0700 Subject: [Mailman-Developers] Re: [Mailman-Announce] Candidate Mailman 2.0.13 patch References: <15678.10644.858948.973667@anthem.wooz.org> Message-ID: <3D3E5A10.2BB4BE8F@whidbey.com> Barry, As I'm running Mailman 2.0.12 on RedHat 6.2, therefore with Python 1.5.2 from the RPM in the original install, and since I've had the problem twice now, I went right for it. After realizing that I couldn't paste the text into a Pico window (the longest lines broke, giving patch errors) I got it patched, configured, and installed without error. I sent a message to my test list and got instant response, with no addition to the error log. However, since I tried each message one at a time this morning, there hadn't been an error logged since. At least here it's only new subscriber confirmations that seem to break things. I subscribed one of my addresses to a list that requires the confirmation, received the confirmation request, replied to it, and was welcomed - so I guess the thing is currently working. Now I'm counting on you to release this patch so that the 2.0.13 to 2.0.14 patch will work on my machine, or perhaps document some way I can remove this patch before installing the real patch to 2.0.13 when the time comes. Van "Barry A. Warsaw" wrote: > As some of you have noticed, Mailman 2.0.12 has some compatibility > problems with Python 1.5.2. In order to correct this, and a few other > minor problems, I want to soon release a version 2.0.13. This time, > however I'd like to enlist your help. ;) > > I have uploaded a candidate patch for 2.0.12 -> 2.0.13 at this url: > > http://sf.net/tracker/index.php?func=detail&aid=585643&group_id=103&atid=300103 > > I would appreciate it if someone (or a few someones) could give this > patch a try. I'm essentially running it on python.org/zope.org, > however I'm using Python 2.1.3 in my production environment. I have > done some limited testing with Python 1.5.2 and this patch and it > seems to go okay. > > I'd especially like to hear from those of you experiencing problems > with MailCommandHandler, if you are running MM2.0.12 with Python > 1.5.2. Does this patch fix things for you? Does it produce any other > tracebacks or warnings in logs/error? > > Thanks for any feedback you can provide. If I get some positive > feedback (or at least, no negative feedback) in a few days, I'd do a > formal release. I expect that to be largely similar to this patch, > with perhaps some documentation updates, unless other problems are > uncovered by your testing. > > Thanks! > -Barry > > _______________________________________________ > Mailman-announce mailing list > Mailman-announce@python.org > http://mail.python.org/mailman/listinfo/mailman-announce -- ---------------------------------------------------------- Sign up now for Quotes of the Day, a handful of quotations on a theme delivered every morning. Enlightenment! Daily, for free! mailto:twisted@whidbey.com?subject=Subscribe_QOTD For web hosting and maintenance, visit Van's home page: http://www.domainvanhorn.com/van/ ---------------------------------------------------------- From barry@zope.com Wed Jul 24 14:06:22 2002 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 24 Jul 2002 09:06:22 -0400 Subject: [Mailman-Developers] Re: [Mailman-Announce] Candidate Mailman 2.0.13 patch References: <15678.10644.858948.973667@anthem.wooz.org> Message-ID: <15678.42574.241723.521685@anthem.wooz.org> >>>>> "ST" == Sotiris Tsimbonis writes: ST> I am running Mailman 2.0.12 with Python 1.5.2 on a linux box, ST> and had problems with torequests.. with this candidate patch ST> they seem to be fixed, as all messages in the queue have now ST> been processed and the queue is clear :-) Excellent! Thanks for the feedback. ST> Thanks for the good work you've been doing all this time :-) You're very welcome! -Barry From noreply@sourceforge.net Wed Jul 24 14:26:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jul 2002 06:26:05 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-584989 ] bounced large messages are deleted! Message-ID: Bugs item #584989, was opened at 2002-07-22 12:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584989&group_id=103 Category: mail delivery Group: 2.1 beta Status: Closed Resolution: Fixed Priority: 5 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) Summary: bounced large messages are deleted! Initial Comment: I`m using 2.1b2+ (July, 22th) and if a message is larger than the maximum allowd size (of this list) it is not bounced or hold for approval succesfully. The message disappears and mailman crashes. Maybe it`s just a mistake in the translation in german mailman.po? Jul 22 17:36:55 2002 (28610) Uncaught runner exception: an integer is required Jul 22 17:36:55 2002 (28610) Traceback (most recent call last): File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 154, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 129, in _dispose status = self._dopipeline(mlist, msg, msgdata, pipeline) File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 152, in _dopipel sys.modules[modname].process(mlist, msg, msgdata) File "/usr/lib/mailman/Mailman/Handlers/Hold.py", line 179, in process MessageTooBig(bodylen, mlist.max_message_size)) File "/usr/lib/mailman/Mailman/Handlers/Hold.py", line 198, in hold_for_approv reason = Utils.wrap(exc.reason_notice()) File "/usr/lib/mailman/Mailman/Handlers/Hold.py", line 103, in reason_notice return _('''Message body is too big: %(size)d bytes with a limit of File "/usr/lib/mailman/Mailman/i18n.py", line 76, in _ return _translation.gettext(s) % dict TypeError: an integer is required ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 09:26 Message: Logged In: YES user_id=12800 Something may have changed in your Python environment? I don't see how that fix could have had anything to do with it! ---------------------------------------------------------------------- Comment By: Peer Heinlein (pheinlein) Date: 2002-07-24 04:14 Message: Logged In: YES user_id=581680 It looks like it works. -Thanks! But now I`m getting the message "`import site` failed; use -v to traceback"?! Peer ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 01:06 Message: Logged In: YES user_id=12800 It does look like it's a bug in the German translation for that message. I'm about to commit a fix to the German catalog; can you try doing a cvs update and see if that fixes your problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584989&group_id=103 From barry@python.org Wed Jul 24 14:28:42 2002 From: barry@python.org (Barry A. Warsaw) Date: Wed, 24 Jul 2002 09:28:42 -0400 Subject: [Mailman-Developers] problems with mailman 2.0.12 qrunner failing to process any messages References: <3D3D73B5.4090006@sonsorol.org> <15678.12194.63109.765977@anthem.wooz.org> <3D3E938A.9090006@sonsorol.org> Message-ID: <15678.43914.582503.51317@anthem.wooz.org> >>>>> "CD" == Chris Dagdigian writes: CD> Last night I patched my 2.0.12 distribution with the patch CD> shown in this email: CD> http://mail.python.org/pipermail-21/mailman-developers/2002-July/012476.html CD> It worked wonderfully -- all mail including the ones that CD> caused qrunner to stop have all been processed fine. No errors CD> at all in the logs as of this morning. CD> So- consider this at least 1 success story for python1.5.2 and CD> MM2.0.12. CD> Much appreciated! Cool, thanks. -Barry From barry@python.org Wed Jul 24 14:29:48 2002 From: barry@python.org (Barry A. Warsaw) Date: Wed, 24 Jul 2002 09:29:48 -0400 Subject: [Mailman-Developers] Modifying mailman to filter archived messages References: <200207151634.51587.laurence@digitalpulp.com> <200207231143.43407.laurence@digitalpulp.com> <15678.12962.668844.226703@anthem.wooz.org> <200207240802.48125.philb@philb.us> Message-ID: <15678.43980.173286.103847@anthem.wooz.org> >>>>> "PB" == Phil Barnett writes: >> Too old. MM2.0.x is in the critical patch only phase of its >> life, and even that is getting difficult to do correctly >> (witness the 2.0.12 problem w/ Python 1.5.2). PB> Has there been an official release of 2.1? Betas only, still. -Barry From barry@python.org Wed Jul 24 14:36:03 2002 From: barry@python.org (Barry A. Warsaw) Date: Wed, 24 Jul 2002 09:36:03 -0400 Subject: [Mailman-Developers] Re: [Mailman-Announce] Candidate Mailman 2.0.13patch References: <15678.10644.858948.973667@anthem.wooz.org> <3D3E5A10.2BB4BE8F@whidbey.com> Message-ID: <15678.44355.611628.600106@anthem.wooz.org> Glad it's working for you now. >>>>> "GAVH" == G Armour Van Horn writes: GAVH> Now I'm counting on you to release this patch so that the GAVH> 2.0.13 to 2.0.14 patch will work on my machine, or perhaps GAVH> document some way I can remove this patch before installing GAVH> the real patch to 2.0.13 when the time comes. When the official 2.0.13 patch is released (let's hope there will be no 2.0.14 ) and you go to apply it with the patch program, you will get warnings that some chunks are already applied. You'll be asked if you want to undo the patch... just answer "no". Patch will leave you with some .rej files which you can ignore. Alternatively, if you haven't customized your system, you can of course just download the full 2.0.13 release tarball, run configure with exactly the same options, and install the new version right overtop the old version. -Barry From noreply@sourceforge.net Wed Jul 24 15:04:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jul 2002 07:04:58 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-585833 ] Forward posts held for approval Message-ID: Bugs item #585833, was opened at 2002-07-24 06:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585833&group_id=103 Category: mail delivery Group: 2.1 beta >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ousmane Wilane (wilane) Assigned to: Nobody/Anonymous (nobody) Summary: Forward posts held for approval Initial Comment: FWIW I'm using the current cvs. When I forward a mail which was held for approval to my email address (oversized mail in this case) I get the provided traceback in my logs and the mail in shunt q: ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 10:04 Message: Logged In: YES user_id=12800 Fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585833&group_id=103 From noreply@sourceforge.net Wed Jul 24 15:26:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jul 2002 07:26:15 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-585776 ] no webauthentification possible Message-ID: Bugs item #585776, was opened at 2002-07-24 04:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585776&group_id=103 Category: Web/CGI Group: 2.1 beta >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) Summary: no webauthentification possible Initial Comment: After updating to 2.1b some of our lists aren`t accessible for admins any more. I`m using the current cvs, but when they try to login mailman crashes: Traceback (most recent call last): File "/usr/lib/mailman/scripts/driver", line 82, in run_main main() File "/usr/lib/mailman/Mailman/Cgi/admin.py", line 82, in main cgidata.getvalue('adminpw', '')): File "/usr/lib/mailman/Mailman/SecurityManager.py", line 206, in WebAuthenticate ac = self.Authenticate(authcontexts, response, user) File "/usr/lib/mailman/Mailman/SecurityManager.py", line 159, in Authenticate elif crypt and crypt.crypt(response, secret[:2]) == secret: TypeError: argument 2 must be string without null bytes, not str ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 10:26 Message: Logged In: YES user_id=12800 I don't quite understand how you could have gotten a secret with null bytes in it, but I've added a try/except around the crypt() call to ignore this exception. If you get it, it's equivalent to a failed response. For future reference, before upgrading to MM2.1, was USE_CRYPT set to 0 or 1? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585776&group_id=103 From noreply@sourceforge.net Wed Jul 24 15:39:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jul 2002 07:39:56 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-585270 ] qrunner fails with RHL7.2 python 1.5.2 Message-ID: Bugs item #585270, was opened at 2002-07-23 03:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585270&group_id=103 Category: mail delivery Group: 2.0.x >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stuart Prescott (themill) Assigned to: Nobody/Anonymous (nobody) Summary: qrunner fails with RHL7.2 python 1.5.2 Initial Comment: qrunner from mailman-2.0.12 (downloaded and installed from the src tarball) fails with Python 1.5.2 from RHL7.2 python-1.5.2-38. Error message from $prefix/logs/error is attached as is a patch that does seem to fix the problem and allow Mailman to work. (I'm not a Python programmer .. I noramlly use P**L so I'm not sure exactly what or why... please treat my patch with the greatest skepticism!) >From the mailing lists, there are quite a few ppl having problems with the RHL distributions of Python -- is this a compatability thing (that we can argue about whether it's RHL or Mailman that is at fault a la gcc for years to come?) ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 10:39 Message: Logged In: YES user_id=12800 This is fixed in the MM2.0.13 candidate patch recently announced. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585270&group_id=103 From noreply@sourceforge.net Wed Jul 24 15:40:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jul 2002 07:40:32 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-577685 ] sh syntax problem in configure Message-ID: Bugs item #577685, was opened at 2002-07-05 03:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=577685&group_id=103 Category: configuring/installing Group: 2.0.x >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: sh syntax problem in configure Initial Comment: in 2.0.12 configure script includes a statement: if [ "$?" == "1" ] which should be in a traditional sh: if [ "$?" = "1" ] (Note single =, not double =) configure fails on solaris 8 with double =, while the error was ignored on FreeBSD. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 10:40 Message: Logged In: YES user_id=12800 This shoudl be fixed in the MM2.0.13 candidate patch, recently announced. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-11 18:30 Message: Logged In: YES user_id=12800 Note that that patch is against configure.in, so you'll need to run autoreconf (or just patch configure by hand). Let me know if that's a problem. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-11 18:29 Message: Logged In: YES user_id=12800 Let's try that again with the checkbox checked off. :/ ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-11 18:28 Message: Logged In: YES user_id=12800 Can you please try the attached patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=577685&group_id=103 From lrosa@mail.hypertrek.info Wed Jul 24 15:52:21 2002 From: lrosa@mail.hypertrek.info (Luigi Rosa) Date: Wed, 24 Jul 2002 16:52:21 +0200 Subject: [Mailman-Developers] 2.1b2 error after reboot Message-ID: <1581167750.20020724165221@mail.hypertrek.info> Hello, half an hour ago I suffered an unscheduled power outage, when my Linux (RH 7.3) rebooted, I had to correct an unlinked i-node in /tmp file system (apparently a .pid file). The qrunner deamon did not start and reported this error: Jul 24 16:34:34 2002 mailmanctl(1040): Traceback (most recent call last): Jul 24 16:34:34 2002 mailmanctl(1040): File "/usr/local/mailman/bin/mailmanctl", line 501, in ? Jul 24 16:34:34 2002 mailmanctl(1040): main() Jul 24 16:34:34 2002 mailmanctl(1040): File "/usr/local/mailman/bin/mailmanctl", line 351, in main Jul 24 16:34:34 2002 mailmanctl(1040): lock = acquire_lock(force) Jul 24 16:34:34 2002 mailmanctl(1040): File "/usr/local/mailman/bin/mailmanctl", line 202, in acquire_lock Jul 24 16:34:34 2002 mailmanctl(1040): lock = acquire_lock_1(force) Jul 24 16:34:34 2002 mailmanctl(1040): File "/usr/local/mailman/bin/mailmanctl", line 196, in acquire_lock_1 Jul 24 16:34:34 2002 mailmanctl(1040): os.unlink(tempfile) Jul 24 16:34:34 2002 mailmanctl(1040): OSError : [Errno 2] No such file or directory: 'master-qrunner.mail.hypertrek.info.25776' Then I did a # service mailman stop and mailman logged this Jul 24 16:35:27 2002 mailmanctl(1112): No child with pid: 25776 Jul 24 16:35:27 2002 mailmanctl(1112): [Errno 3] No such process Jul 24 16:35:27 2002 mailmanctl(1112): Stale pid file removed. after that I did a # service mailman start and everything was Ok. This could be a serious issue in case of unattended machines, is there a solution for this error? -- Best regards, Luigi mailto:lrosa@mail.hypertrek.info From barry@python.org Wed Jul 24 16:21:07 2002 From: barry@python.org (Barry A. Warsaw) Date: Wed, 24 Jul 2002 11:21:07 -0400 Subject: [Mailman-Developers] 2.1b2 error after reboot References: <1581167750.20020724165221@mail.hypertrek.info> Message-ID: <15678.50659.224532.721925@anthem.wooz.org> >>>>> "LR" == Luigi Rosa writes: LR> Hello, half an hour ago I suffered an unscheduled power LR> outage, when my Linux (RH 7.3) rebooted, I had to correct an LR> unlinked i-node in /tmp file system (apparently a .pid file). LR> The qrunner deamon did not start and reported this error: Jul LR> Then I did a LR> # service mailman stop LR> and mailman logged this LR> Jul 24 16:35:27 2002 mailmanctl(1112): No child with pid: LR> 25776 Jul 24 16:35:27 2002 mailmanctl(1112): [Errno 3] No such LR> process Jul 24 16:35:27 2002 mailmanctl(1112): Stale pid file LR> removed. LR> after that I did a LR> # service mailman start LR> and everything was Ok. LR> This could be a serious issue in case of unattended machines, LR> is there a solution for this error? Sounds like you don't have things set up to restart on reboot properly. Did you follow the installation directions to chkconfig --add the mailman script to the proper run levels? -Barry From noreply@sourceforge.net Wed Jul 24 16:25:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jul 2002 08:25:24 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-585484 ] virtual domain lists misdirect autoreply Message-ID: Bugs item #585484, was opened at 2002-07-23 12:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585484&group_id=103 Category: bounce detection Group: None Status: Open Resolution: None Priority: 5 Submitted By: Byron T. Watts (btwatts) Assigned to: Nobody/Anonymous (nobody) Summary: virtual domain lists misdirect autoreply Initial Comment: Using mailman with virtual domain hosting. Bounced messages for a particular list are going to the wrong list administrator (not even on the same domain). The particular notices that I'm seeing misdirected, are the useridi> is on vacation messages. I am not certain whether other messages are being similarly misdirected. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 11:25 Message: Logged In: YES user_id=12800 Sorry, I'll need more information here. Start with the basics: what OS, what MTA, what version of Python, what version of Mailman. How do you have your MTA configured? Have you set up virtual domain support in Mailman properly (differs depending on the version of Mailman you're using). Please include version numbers for all related software. Also if you can provide a reproducible recipe for seeing the bug, or at least attach copies of misdirected messages, these things would help. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585484&group_id=103 From noreply@sourceforge.net Wed Jul 24 16:26:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jul 2002 08:26:10 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-585833 ] Forward posts held for approval Message-ID: Bugs item #585833, was opened at 2002-07-24 10:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585833&group_id=103 Category: mail delivery Group: 2.1 beta Status: Closed Resolution: Fixed Priority: 5 Submitted By: Ousmane Wilane (wilane) Assigned to: Nobody/Anonymous (nobody) Summary: Forward posts held for approval Initial Comment: FWIW I'm using the current cvs. When I forward a mail which was held for approval to my email address (oversized mail in this case) I get the provided traceback in my logs and the mail in shunt q: ---------------------------------------------------------------------- >Comment By: Ousmane Wilane (wilane) Date: 2002-07-24 15:26 Message: Logged In: YES user_id=47556 Oops! After cvs -q up -P -d, The bug stood there with the same traceback. Maybe I'm doing something wrong but don't know what ... :) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 14:04 Message: Logged In: YES user_id=12800 Fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585833&group_id=103 From lrosa@mail.hypertrek.info Wed Jul 24 16:31:27 2002 From: lrosa@mail.hypertrek.info (Luigi Rosa) Date: Wed, 24 Jul 2002 17:31:27 +0200 Subject: [Mailman-Developers] 2.1b2 error after reboot In-Reply-To: <15678.50659.224532.721925@anthem.wooz.org> References: <1581167750.20020724165221@mail.hypertrek.info> <15678.50659.224532.721925@anthem.wooz.org> Message-ID: <1503514031.20020724173127@mail.hypertrek.info> Hello Barry, Wednesday, July 24, 2002, 5:21:07 PM, you wrote: BAW> Sounds like you don't have things set up to restart on reboot BAW> properly. Did you follow the installation directions to chkconfig BAW> --add the mailman script to the proper run levels? Yes, this is the chiconfig status for mailman: mailman 0:off 1:off 2:on 3:on 4:on 5:on 6:off note that my system starts on runlevel 3 Ciao, luigi -- Best regards, Luigi mailto:lrosa@mail.hypertrek.info From noreply@sourceforge.net Wed Jul 24 16:28:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jul 2002 08:28:59 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-585229 ] opening holes by changing permissions? Message-ID: Bugs item #585229, was opened at 2002-07-22 23:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585229&group_id=103 Category: configuring/installing Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Paul Marshall (paulmarshll) Assigned to: Nobody/Anonymous (nobody) Summary: opening holes by changing permissions? Initial Comment: I was having problems adding a list in Mailman 2.1beta via the web interface, it was giving me an error regarding permissions to the mailman/data/aliases.db file. This is the error I got: ... File "/var/mailman/Mailman/MTA/Postfix.py", line 46, in _update_maps raise RuntimeError, msg % (acmd, status, errstr) RuntimeError: command failed: /usr/sbin/postalias /var/mailman/data/aliases (status: 1, Operation not permitted) To fix this I changed the permissions on this file so apache could write to it. chmod a+w aliases.db This did fix the problem of creating and deleting lists via the web interface. Does anyone know if this would open up any security holes? Is there another way to fix the permissions problem that is more logical? Thanks for your help. Paul Marshall ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 11:28 Message: Logged In: YES user_id=12800 You shouldn't need to do this if you've followed the directions in README.POSTFIX. The key issue is that aliases and aliases.db must be group owned by `mailman' and must be group writeable. Since the cgi scripts are setgid mailman Apache should have no problems writing the file. And since Postfix filter prog is also setgid mailman, it should have no problems either. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585229&group_id=103 From noreply@sourceforge.net Wed Jul 24 16:30:05 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jul 2002 08:30:05 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-582891 ] Mailman converting = to =3D Message-ID: Bugs item #582891, was opened at 2002-07-17 11:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=582891&group_id=103 Category: (un)subscribing Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Jake Rosenbalm (jakerose) Assigned to: Nobody/Anonymous (nobody) Summary: Mailman converting = to =3D Initial Comment: We have a page allowing a user to submit thier email to subscribe to lists. The text sent is subscribe nodigest address=jakerose@yahoo.com. However, the coomand being processed by mailman is subscribe nodigest address=3Djakerose@yahoo.com, where the = is converted to =3D. ANy ideas? ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 11:30 Message: Logged In: YES user_id=12800 It's likely something else in your tool chain (probably your MTA) is doing the quoted-printable conversion. Mailman won't do that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=582891&group_id=103 From noreply@sourceforge.net Wed Jul 24 16:31:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jul 2002 08:31:10 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-582274 ] Duplicate Subscription Request Message-ID: Bugs item #582274, was opened at 2002-07-16 10:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=582274&group_id=103 Category: (un)subscribing Group: 2.0.x >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: rich cowan (leftlink) Assigned to: Nobody/Anonymous (nobody) Summary: Duplicate Subscription Request Initial Comment: Someone submitted a subscription request twice and instead of rejecting the second request, Mailman allowed it and it appeared twice in the subscriber approve window. here is an example of how this appeared: Date: Tue, 16 Jul 2002 06:25:19 -0400 Subject: 2 devel admin request(s) waiting From: devel-admin@lists.democracygroups.org To: devel-admin@lists.democracygroups.org X-Ack: no X-BeenThere: devel@lists.democracygroups.org X-Mailman-Version: 2.0.9 Precedence: bulk Message-Id: Sender: devel-owner@lists.democracygroups.org Errors-To: devel-owner@lists.democracygroups.org X-BeenThere: devel@lists.democracygroups.org List-Help: List-Post: List-Subscribe: , List-Id: OC Software Development Volunteer List-Unsubscribe: , List-Archive: Status: The devel@lists.democracygroups.org mailing list has 2 request(s) waiting for your consideration at: http://lists.democracygroups.org/mailman/a dmindb/devel Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending subscriptions: ksnyder@..ny.org Tue Jul 16 05:10:03 2002 ksnyder@..ny.org Tue Jul 16 05:20:02 2002 ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 11:31 Message: Logged In: YES user_id=12800 Yup, this is a deficiency of MM2.0. I think it's a minor problem and since MM2.0 is in critical patch phase only, I don't plan on fixing this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=582274&group_id=103 From noreply@sourceforge.net Wed Jul 24 16:36:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jul 2002 08:36:02 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-579908 ] Very poor configuration design Message-ID: Bugs item #579908, was opened at 2002-07-10 20:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=579908&group_id=103 Category: configuring/installing Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bob Tanner (tanner) Assigned to: Nobody/Anonymous (nobody) Summary: Very poor configuration design Initial Comment: The way configure is setup it seems to assume that you are building mailman ON the box you will be installing it. This is a terrible design decision. Make for creating packages a total nightmare. Forcing a package builder to add entries into /etc/passwd and /etc/group, is another bad design decision. Forcing a package builder to have all the directories setup and proper permissions during build it a another bad design decision. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 11:36 Message: Logged In: YES user_id=12800 Sorry, I don't agree. They were good design decisions made for intentional reasons. You can disagree with them or suggest better ways to accomplish other goals, of course. First, sorry, but security demands a mailman user and group be added to the system. I don't think this is much different than a lot of other server type software packages, such as mail daemons. As for the second point, in MM2.1 you will be able to override some of the decisions at configure time, but it seems to me that most autoconf based programs will have similar issues, so Mailman's not unique here. One of the biggest problems IMO is that the gid's are compiled into the C wrappers. While this is very good for a local install, it probably doesn't work well for a package install. I'd be open to suggestions (or better yet, patches) to improve the situation for package builds. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=579908&group_id=103 From noreply@sourceforge.net Wed Jul 24 16:44:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jul 2002 08:44:19 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-585229 ] opening holes by changing permissions? Message-ID: Bugs item #585229, was opened at 2002-07-22 22:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585229&group_id=103 Category: configuring/installing Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Paul Marshall (paulmarshll) Assigned to: Nobody/Anonymous (nobody) Summary: opening holes by changing permissions? Initial Comment: I was having problems adding a list in Mailman 2.1beta via the web interface, it was giving me an error regarding permissions to the mailman/data/aliases.db file. This is the error I got: ... File "/var/mailman/Mailman/MTA/Postfix.py", line 46, in _update_maps raise RuntimeError, msg % (acmd, status, errstr) RuntimeError: command failed: /usr/sbin/postalias /var/mailman/data/aliases (status: 1, Operation not permitted) To fix this I changed the permissions on this file so apache could write to it. chmod a+w aliases.db This did fix the problem of creating and deleting lists via the web interface. Does anyone know if this would open up any security holes? Is there another way to fix the permissions problem that is more logical? Thanks for your help. Paul Marshall ---------------------------------------------------------------------- >Comment By: Paul Marshall (paulmarshll) Date: 2002-07-24 10:44 Message: Logged In: YES user_id=582441 Thanks for the help bwarsaw, its working now and I don't have a+w on aliases.db Paul ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 10:28 Message: Logged In: YES user_id=12800 You shouldn't need to do this if you've followed the directions in README.POSTFIX. The key issue is that aliases and aliases.db must be group owned by `mailman' and must be group writeable. Since the cgi scripts are setgid mailman Apache should have no problems writing the file. And since Postfix filter prog is also setgid mailman, it should have no problems either. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585229&group_id=103 From noreply@sourceforge.net Wed Jul 24 16:45:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jul 2002 08:45:33 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-579285 ] gate_news attempts connect to bad hosts Message-ID: Bugs item #579285, was opened at 2002-07-09 16:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=579285&group_id=103 Category: nntp/news Group: 2.0.x >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Steve Fox (drfickle) Assigned to: Nobody/Anonymous (nobody) Summary: gate_news attempts connect to bad hosts Initial Comment: I've been having gate_news spew out 'Connection refused' errors every five minutes for quite some time now. I finally tracked down what the problem is, and hopefully someone more skilled in Python than I can create a simple fix. In the open_news function it doesn't check whether the mlist.nntp_host variable is valid or not (in my case it was a null string). A simple if check would solve the problem here, but I think that's addressing the symptom, not the problem. Rather I think the real problem is that the MailList class sets gateway_to_mail to "true" (I'm not sure what the real value is), even if the nntp host name is invalid. Then the process_lists function assumes that nntp_host is valid and calls open_newsgroup on it. I would suggest that if the nntp_host is invalid, that the MailList class not set gateway_to_mail to be "true". Thanks! ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 11:45 Message: Logged In: YES user_id=12800 While I won't fix this for MM2.0, in MM2.1, you now cannot enable gatewaying unless both the nntp_host and linked_newsgroup fields are filled in. It's too expensive and annoying to do further validation (i.e. that the given host exists and accepts nntp connections, and that the newsgroup is a valid newsgroup on the host). ---------------------------------------------------------------------- Comment By: Steve Fox (drfickle) Date: 2002-07-09 16:32 Message: Logged In: YES user_id=17512 I forgot to mention that gateway_to_mail seems to be set "true" anytime the mail-to-news page contains any non-default values. That is, even if hostname and newsgroup are blank, but one or more of the radio buttons are set to yes, gate_to_mail will be "true". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=579285&group_id=103 From noreply@sourceforge.net Wed Jul 24 16:46:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jul 2002 08:46:32 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-585833 ] Forward posts held for approval Message-ID: Bugs item #585833, was opened at 2002-07-24 06:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585833&group_id=103 Category: mail delivery Group: 2.1 beta Status: Closed Resolution: Fixed Priority: 5 Submitted By: Ousmane Wilane (wilane) Assigned to: Nobody/Anonymous (nobody) Summary: Forward posts held for approval Initial Comment: FWIW I'm using the current cvs. When I forward a mail which was held for approval to my email address (oversized mail in this case) I get the provided traceback in my logs and the mail in shunt q: ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 11:46 Message: Logged In: YES user_id=12800 Be sure you "mailmanctl restart" :) ---------------------------------------------------------------------- Comment By: Ousmane Wilane (wilane) Date: 2002-07-24 11:26 Message: Logged In: YES user_id=47556 Oops! After cvs -q up -P -d, The bug stood there with the same traceback. Maybe I'm doing something wrong but don't know what ... :) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 10:04 Message: Logged In: YES user_id=12800 Fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585833&group_id=103 From barry@python.org Wed Jul 24 16:47:43 2002 From: barry@python.org (Barry A. Warsaw) Date: Wed, 24 Jul 2002 11:47:43 -0400 Subject: [Mailman-Developers] 2.1b2 error after reboot References: <1581167750.20020724165221@mail.hypertrek.info> <15678.50659.224532.721925@anthem.wooz.org> <1503514031.20020724173127@mail.hypertrek.info> Message-ID: <15678.52255.776133.670594@anthem.wooz.org> >>>>> "LR" == Luigi Rosa writes: LR> Wednesday, July 24, 2002, 5:21:07 PM, you wrote: BAW> Sounds like you don't have things set up to restart on reboot BAW> properly. Did you follow the installation directions to BAW> chkconfig --add the mailman script to the proper run levels? LR> Yes, this is the chiconfig status for mailman: LR> mailman 0:off 1:off 2:on 3:on 4:on 5:on 6:off LR> note that my system starts on runlevel 3 Hmm, I guess you need to check your logs for any errors that might be occuring during boot up. Restart works fine for me on RH7.3 (and 6.1). -Barry From lrosa@mail.hypertrek.info Wed Jul 24 16:54:56 2002 From: lrosa@mail.hypertrek.info (Luigi Rosa) Date: Wed, 24 Jul 2002 17:54:56 +0200 Subject: [Mailman-Developers] 2.1b2 error after reboot In-Reply-To: <15678.52255.776133.670594@anthem.wooz.org> References: <1581167750.20020724165221@mail.hypertrek.info> <15678.50659.224532.721925@anthem.wooz.org> <1503514031.20020724173127@mail.hypertrek.info> <15678.52255.776133.670594@anthem.wooz.org> Message-ID: <844922765.20020724175456@mail.hypertrek.info> Hello Barry, Wednesday, July 24, 2002, 5:47:43 PM, you wrote: BAW> Hmm, I guess you need to check your logs for any errors that might be BAW> occuring during boot up. Restart works fine for me on RH7.3 (and BAW> 6.1). The boot was not after a graceful shutdown, but after a power loss. Check my last message with the steps to replicate the error without rebooting. Ciao, luigi -- Best regards, Luigi mailto:lrosa@mail.hypertrek.info From noreply@sourceforge.net Wed Jul 24 17:11:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jul 2002 09:11:31 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-585776 ] no webauthentification possible Message-ID: Bugs item #585776, was opened at 2002-07-24 10:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585776&group_id=103 Category: Web/CGI Group: 2.1 beta Status: Closed Resolution: Fixed Priority: 5 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) Summary: no webauthentification possible Initial Comment: After updating to 2.1b some of our lists aren`t accessible for admins any more. I`m using the current cvs, but when they try to login mailman crashes: Traceback (most recent call last): File "/usr/lib/mailman/scripts/driver", line 82, in run_main main() File "/usr/lib/mailman/Mailman/Cgi/admin.py", line 82, in main cgidata.getvalue('adminpw', '')): File "/usr/lib/mailman/Mailman/SecurityManager.py", line 206, in WebAuthenticate ac = self.Authenticate(authcontexts, response, user) File "/usr/lib/mailman/Mailman/SecurityManager.py", line 159, in Authenticate elif crypt and crypt.crypt(response, secret[:2]) == secret: TypeError: argument 2 must be string without null bytes, not str ---------------------------------------------------------------------- >Comment By: Peer Heinlein (pheinlein) Date: 2002-07-24 18:11 Message: Logged In: YES user_id=581680 Don`t ask me how this happend :-) It`s working now - thanks a lot. I`m really suprised and very happy about the really fast responses! USE_CRYPT was set to 1 before upgrading. I never changed it. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 16:26 Message: Logged In: YES user_id=12800 I don't quite understand how you could have gotten a secret with null bytes in it, but I've added a try/except around the crypt() call to ignore this exception. If you get it, it's equivalent to a failed response. For future reference, before upgrading to MM2.1, was USE_CRYPT set to 0 or 1? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585776&group_id=103 From noreply@sourceforge.net Wed Jul 24 17:24:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jul 2002 09:24:11 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-584989 ] bounced large messages are deleted! Message-ID: Bugs item #584989, was opened at 2002-07-22 18:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584989&group_id=103 Category: mail delivery Group: 2.1 beta Status: Closed Resolution: Fixed Priority: 5 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) Summary: bounced large messages are deleted! Initial Comment: I`m using 2.1b2+ (July, 22th) and if a message is larger than the maximum allowd size (of this list) it is not bounced or hold for approval succesfully. The message disappears and mailman crashes. Maybe it`s just a mistake in the translation in german mailman.po? Jul 22 17:36:55 2002 (28610) Uncaught runner exception: an integer is required Jul 22 17:36:55 2002 (28610) Traceback (most recent call last): File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 154, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 129, in _dispose status = self._dopipeline(mlist, msg, msgdata, pipeline) File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 152, in _dopipel sys.modules[modname].process(mlist, msg, msgdata) File "/usr/lib/mailman/Mailman/Handlers/Hold.py", line 179, in process MessageTooBig(bodylen, mlist.max_message_size)) File "/usr/lib/mailman/Mailman/Handlers/Hold.py", line 198, in hold_for_approv reason = Utils.wrap(exc.reason_notice()) File "/usr/lib/mailman/Mailman/Handlers/Hold.py", line 103, in reason_notice return _('''Message body is too big: %(size)d bytes with a limit of File "/usr/lib/mailman/Mailman/i18n.py", line 76, in _ return _translation.gettext(s) % dict TypeError: an integer is required ---------------------------------------------------------------------- >Comment By: Peer Heinlein (pheinlein) Date: 2002-07-24 18:24 Message: Logged In: YES user_id=581680 I really don`t know how python works and how to help myself. Maybe something has changed - I installed the package python-devel and python tk. There`s a traceback when I start "python -v": [...] # /usr/lib/python2.2/stat.pyc matches /usr/lib/python2.2/stat.py import stat # precompiled from /usr/lib/python2.2/stat.pyc # /usr/lib/python2.2/UserDict.pyc matches /usr/lib/python2.2/UserDict.py import UserDict # precompiled from /usr/lib/python2.2/UserDict.pyc 'import site' failed; traceback: Traceback (most recent call last): File "/var/tmp/python-2.2-build//usr/lib/python2.2/site.py", line 177, in ? addsitedir(sitedir) File "/var/tmp/python-2.2-build//usr/lib/python2.2/site.py", line 128, in addsitedir addpackage(sitedir, name) File "/var/tmp/python-2.2-build//usr/lib/python2.2/site.py", line 151, in addpackage exec dir File "", line 1, in ? ImportError: No module named japanese Python 2.2 (#1, Mar 26 2002, 15:46:04) [GCC 2.95.3 20010315 (SuSE)] on linux2 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 15:26 Message: Logged In: YES user_id=12800 Something may have changed in your Python environment? I don't see how that fix could have had anything to do with it! ---------------------------------------------------------------------- Comment By: Peer Heinlein (pheinlein) Date: 2002-07-24 10:14 Message: Logged In: YES user_id=581680 It looks like it works. -Thanks! But now I`m getting the message "`import site` failed; use -v to traceback"?! Peer ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 07:06 Message: Logged In: YES user_id=12800 It does look like it's a bug in the German translation for that message. I'm about to commit a fix to the German catalog; can you try doing a cvs update and see if that fixes your problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584989&group_id=103 From ckolar@imsa.edu Wed Jul 24 17:24:13 2002 From: ckolar@imsa.edu (Christopher Kolar) Date: Wed, 24 Jul 2002 11:24:13 -0500 Subject: [Mailman-Developers] Mm documentation server change Message-ID: <5.1.0.14.2.20020724112046.035f0338@staffmail.imsa.edu> IMSA will be making some significant server changes this weekend, changes that will impact the location of the Mailman documents that we host. The new URL will be: http://staff.imsa.edu/~ckolar/mailman The pages will no longer be hosted on www.imsa.edu. There will be NO URL FORWARDING when the change is made this Saturday morning, so please change links as necessary. I will try to sort through the logs and pull out the URLs of people linking in to try to contact them personally, but if you maintain a page with a link and are reading this note please take appropriate action. Sorry about the short notice on this, I just found out myself. --chris /////\\\\\/////\\\\\ Christopher G. Kolar Coordinator of Information Technology Integration Illinois Mathematics and Science Academy ckolar@imsa.edu -- www.imsa.edu/~ckolar -- PGP Public Key ID: 0xC6492C72 Information literacy news, tools, and programs: infoliteracy-subscribe@iti.cnsnet.imsa.eduFrom laurence@digitalpulp.com Wed Jul 24 17:28:56 2002 From: laurence@digitalpulp.com (Laurence Berland) Date: Wed, 24 Jul 2002 12:28:56 -0400 Subject: Fwd: Re: [Mailman-Developers] Modifying mailman to filter archived messages Message-ID: <200207241228.56054.laurence@digitalpulp.com> On Wednesday 24 July 2002 12:48 am, you wrote: > E.g. you'd do msg.get(fieldname) to get the contents of a header, and > "del msg[fieldname] ; msg[fieldname] =3D value" to replace the contents > of a header. msg.attach(attachment) or msg.set_payload(body) to > manipulate the body of a message, etc. Just to clarify, body=3Dmsg.get_payload() sets body to the msg payload, a= nd msg.set_payload(body) sets the msg payload to body, right? I'll probably be testing this today and submitting a patch against 2.1...= I don't know if you would want to override feature-freeze for this, but it'= s a really incredibly short thing, so it might not be a problem... Laurence From laurence@digitalpulp.com Wed Jul 24 18:03:15 2002 From: laurence@digitalpulp.com (Laurence Berland) Date: Wed, 24 Jul 2002 13:03:15 -0400 Subject: [Mailman-Developers] Modifying mailman to filter archived messages In-Reply-To: <15678.55345.31486.582961@anthem.wooz.org> References: <200207151634.51587.laurence@digitalpulp.com> <200207241214.04173.laurence@digitalpulp.com> <15678.55345.31486.582961@anthem.wooz.org> Message-ID: <200207241303.15969.laurence@digitalpulp.com> On Wednesday 24 July 2002 12:39 pm, Barry A. Warsaw wrote: > >>>>> "LB" =3D=3D Laurence Berland writes: > LB> Just to clarify, body=3Dmsg.get_payload() sets body to the msg > LB> payload, and msg.set_payload(body) sets the msg payload to > LB> body, right? > > Basically, yes, as long as (in the set_payload() situation) you've got > a text/plain message. Whether to use set_payload() or attach() > depends on whether the container is multipart or not. Ouch-I guess I missed this little detail. I'm trying to get an idea of ho= w=20 best to do this. Does this work? (easier in pcode than english): if not msg.is_multipart and msg_type=3D=3D"text/plain": =09bod=3Dmsg.get_payload() =09 =09msg.set_payload(bod) elif msg.get_type() =3D=3D 'multipart/mixed': =09for part in msg.walk() =09=09if part_type =3D=3D "text/plain": =09=09=09bod=3Dpart.get_payload() =09=09=09 =09=09=09part.set_payload(bod) I've sort of cobbled this together on the fly here, so if it's totally of= f=20 please forgive my ignorance, stupidity, lack of sleep, etc... Laurence From noreply@sourceforge.net Wed Jul 24 18:05:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jul 2002 10:05:37 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-579285 ] gate_news attempts connect to bad hosts Message-ID: Bugs item #579285, was opened at 2002-07-09 15:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=579285&group_id=103 Category: nntp/news Group: 2.0.x Status: Closed Resolution: Fixed Priority: 5 Submitted By: Steve Fox (drfickle) Assigned to: Nobody/Anonymous (nobody) Summary: gate_news attempts connect to bad hosts Initial Comment: I've been having gate_news spew out 'Connection refused' errors every five minutes for quite some time now. I finally tracked down what the problem is, and hopefully someone more skilled in Python than I can create a simple fix. In the open_news function it doesn't check whether the mlist.nntp_host variable is valid or not (in my case it was a null string). A simple if check would solve the problem here, but I think that's addressing the symptom, not the problem. Rather I think the real problem is that the MailList class sets gateway_to_mail to "true" (I'm not sure what the real value is), even if the nntp host name is invalid. Then the process_lists function assumes that nntp_host is valid and calls open_newsgroup on it. I would suggest that if the nntp_host is invalid, that the MailList class not set gateway_to_mail to be "true". Thanks! ---------------------------------------------------------------------- >Comment By: Steve Fox (drfickle) Date: 2002-07-24 12:05 Message: Logged In: YES user_id=17512 That sounds great. Thanks. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 10:45 Message: Logged In: YES user_id=12800 While I won't fix this for MM2.0, in MM2.1, you now cannot enable gatewaying unless both the nntp_host and linked_newsgroup fields are filled in. It's too expensive and annoying to do further validation (i.e. that the given host exists and accepts nntp connections, and that the newsgroup is a valid newsgroup on the host). ---------------------------------------------------------------------- Comment By: Steve Fox (drfickle) Date: 2002-07-09 15:32 Message: Logged In: YES user_id=17512 I forgot to mention that gateway_to_mail seems to be set "true" anytime the mail-to-news page contains any non-default values. That is, even if hostname and newsgroup are blank, but one or more of the radio buttons are set to yes, gate_to_mail will be "true". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=579285&group_id=103 From noreply@sourceforge.net Wed Jul 24 18:26:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jul 2002 10:26:16 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-585833 ] Forward posts held for approval Message-ID: Bugs item #585833, was opened at 2002-07-24 10:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585833&group_id=103 Category: mail delivery Group: 2.1 beta Status: Closed Resolution: Fixed Priority: 5 Submitted By: Ousmane Wilane (wilane) Assigned to: Nobody/Anonymous (nobody) Summary: Forward posts held for approval Initial Comment: FWIW I'm using the current cvs. When I forward a mail which was held for approval to my email address (oversized mail in this case) I get the provided traceback in my logs and the mail in shunt q: ---------------------------------------------------------------------- >Comment By: Ousmane Wilane (wilane) Date: 2002-07-24 17:26 Message: Logged In: YES user_id=47556 I swear I did restart it :):) More seriously I stop postfix, apache, mailman before upgrading as outlined in the UPGRADING file ... :) I also did verify that ListAdmin.py 2.39 was checked out This time I'll paste the traceback here (it's thrown in logs/error when I try to unshunt the messages): Jul 24 17:17:25 2002 (30049) Traceback (most recent call last): File "/usr/local/mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/usr/local/mailman/Mailman/Queue/Runner.py", line 154, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Queue/OutgoingRunner.py", line 61, in _dispose self._func(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Handlers/SMTPDirect.py", line 134, in process deliveryfunc(mlist, msg, msgdata, envsender, refused, conn) File "/usr/local/mailman/Mailman/Handlers/SMTPDirect.py", line 307, in bulkdeliver msgtext = msg.as_string() File "/usr/local/mailman/pythonlib/email/Message.py", line 99, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/local/mailman/pythonlib/email/Generator.py", line 81, in flatten self._write(msg) File "/usr/local/mailman/pythonlib/email/Generator.py", line 109, in _write self._dispatch(msg) File "/usr/local/mailman/pythonlib/email/Generator.py", line 141, in _dispatch meth(msg) File "/usr/local/mailman/pythonlib/email/Generator.py", line 283, in _handle_message g.flatten(msg.get_payload(0), unixfrom=0) File "/usr/local/mailman/pythonlib/email/Message.py", line 167, in get_payload raise TypeError, i TypeError: 0 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 15:46 Message: Logged In: YES user_id=12800 Be sure you "mailmanctl restart" :) ---------------------------------------------------------------------- Comment By: Ousmane Wilane (wilane) Date: 2002-07-24 15:26 Message: Logged In: YES user_id=47556 Oops! After cvs -q up -P -d, The bug stood there with the same traceback. Maybe I'm doing something wrong but don't know what ... :) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 14:04 Message: Logged In: YES user_id=12800 Fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585833&group_id=103 From ml+mm-dev@riyescott.com Wed Jul 24 19:03:07 2002 From: ml+mm-dev@riyescott.com (Dale) Date: Wed, 24 Jul 2002 11:03:07 -0700 Subject: [Mailman-Developers] 2.1b2 error after reboot In-Reply-To: <15678.50659.224532.721925@anthem.wooz.org>; from barry@python.org on Wed, Jul 24, 2002 at 11:21:07AM -0400 References: <1581167750.20020724165221@mail.hypertrek.info> <15678.50659.224532.721925@anthem.wooz.org> Message-ID: <20020724110307.A13257@cupro.opengvs.com> On Wed, Jul 24, 2002 at 11:21:07AM -0400, Barry A. Warsaw wrote: > >>>>> "LR" == Luigi Rosa writes: > > LR> Hello, half an hour ago I suffered an unscheduled power > LR> outage, when my Linux (RH 7.3) rebooted, I had to correct an > LR> unlinked i-node in /tmp file system (apparently a .pid file). > > LR> The qrunner deamon did not start and reported this error: Jul > LR> Then I did a > > LR> # service mailman stop > > LR> and mailman logged this > > LR> Jul 24 16:35:27 2002 mailmanctl(1112): No child with pid: > LR> 25776 Jul 24 16:35:27 2002 mailmanctl(1112): [Errno 3] No such > LR> process Jul 24 16:35:27 2002 mailmanctl(1112): Stale pid file > LR> removed. > > LR> after that I did a > > LR> # service mailman start > > LR> and everything was Ok. > > LR> This could be a serious issue in case of unattended machines, > LR> is there a solution for this error? > > Sounds like you don't have things set up to restart on reboot > properly. Did you follow the installation directions to chkconfig > --add the mailman script to the proper run levels? Problem diagnosed with suggested fix (works for me) at: [ 565917 ] mailmanctl bombs after unclean shutdown https://sourceforge.net/tracker/index.php?func=detail&aid=565917&group_id=103&atid=100103 From noreply@sourceforge.net Wed Jul 24 19:51:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jul 2002 11:51:02 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-565917 ] mailmanctl bombs after unclean shutdown Message-ID: Bugs item #565917, was opened at 2002-06-07 14:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=565917&group_id=103 Category: command line scripts Group: 2.1 beta >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Dale Stimson (dstimson) Assigned to: Nobody/Anonymous (nobody) Summary: mailmanctl bombs after unclean shutdown Initial Comment: Environment: Red Hat 7.3, latest errata, Mailman 2.1b2 I see that this problem still exists in the current CVS as of a day or two ago. When mailman restarts after having been shutdown uncleanly (e.g., when rebooting following a crash), it bombs leaving no qrunners active with the following in the log: Jun 04 18:05:13 2002 mailmanctl(1572): Traceback (most recent call last): Jun 04 18:05:13 2002 mailmanctl(1572): File "/var/mailman/bin/mailmanctl", line 502, in ? Jun 04 18:05:13 2002 mailmanctl(1572): main() Jun 04 18:05:13 2002 mailmanctl(1572): File "/var/mailman/bin/mailmanctl", line 352, in main Jun 04 18:05:13 2002 mailmanctl(1572): lock = acquire_lock(force) Jun 04 18:05:13 2002 mailmanctl(1572): File "/var/mailman/bin/mailmanctl", line 203, in acquire_lock Jun 04 18:05:13 2002 mailmanctl(1572): lock = acquire_lock_1(force) Jun 04 18:05:13 2002 mailmanctl(1572): File "/var/mailman/bin/mailmanctl", line 197, in acquire_lock_1 Jun 04 18:05:13 2002 mailmanctl(1572): os.unlink(tempfile) Jun 04 18:05:13 2002 mailmanctl(1572): OSError : [Errno 2] No such file or directory: 'master-qrunner.cupro.opengvs.com.9014' Diagnosis: In file bin/mailmanctl, function acquire_lock_1 is attempting to delete the lock file left over from the last run. It calls function get_lock_data to find the name of the old lock file that is to be deleted. Function get_lock_data (incorrectly) returns the file name with the directory part of the path stripped, thereby causing the delete to fail and the trap to occur. Function get_lock_data should instead return the entire file path, including directories. The patch given below corrects the behavior of get_lock_data. As an aside, it would be nice if acquire_lock_1 was more forgiving if the os.unlink calls fail due to "no such file". I have not submitted a patch for that as I don't know the appropriate python semantics. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 14:51 Message: Logged In: YES user_id=12800 Thanks! I'm going to fix this in a slightly different way, but your patch definitely paved the way. ---------------------------------------------------------------------- Comment By: E. Viennet (anotong) Date: 2002-07-07 03:26 Message: Logged In: YES user_id=396722 I also observed this behavior. I did patch my mailman (mailmanctl, acquire_lock_1) by putting try/except pairs around each call to unlink(), but I'm not sure it's the correct fix. ---------------------------------------------------------------------- Comment By: Dale Stimson (dstimson) Date: 2002-06-07 14:14 Message: Logged In: YES user_id=559033 Please ignore uploaded file sf1.txt (it won't let me delete it), which has cruft in it (the problem report text), as opposed to just the patch). The file with just the patch is sf.txt. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=565917&group_id=103 From barry@python.org Wed Jul 24 19:51:53 2002 From: barry@python.org (Barry A. Warsaw) Date: Wed, 24 Jul 2002 14:51:53 -0400 Subject: [Mailman-Developers] 2.1b2 error after reboot References: <1581167750.20020724165221@mail.hypertrek.info> <15678.50659.224532.721925@anthem.wooz.org> <20020724110307.A13257@cupro.opengvs.com> Message-ID: <15678.63305.824114.11683@anthem.wooz.org> >>>>> "D" == Dale writes: Dale> Problem diagnosed with suggested fix (works for me) at: Dale> [ 565917 ] mailmanctl bombs after unclean shutdown Thanks Dale. I fixed this in a slightly different way, but I appreciate the patch submission. Should be fixed in cvs now. -Barry From lrosa@mail.hypertrek.info Wed Jul 24 20:14:58 2002 From: lrosa@mail.hypertrek.info (Luigi Rosa) Date: Wed, 24 Jul 2002 21:14:58 +0200 Subject: [Mailman-Developers] 2.1b2 error after reboot In-Reply-To: <15678.63305.824114.11683@anthem.wooz.org> References: <1581167750.20020724165221@mail.hypertrek.info> <15678.50659.224532.721925@anthem.wooz.org> <20020724110307.A13257@cupro.opengvs.com> <15678.63305.824114.11683@anthem.wooz.org> Message-ID: <1177156062.20020724211458@mail.hypertrek.info> Hello Barry, BAW> Dale> [ 565917 ] mailmanctl bombs after unclean shutdown BAW> Thanks Dale. I fixed this in a slightly different way, but I BAW> appreciate the patch submission. BAW> Should be fixed in cvs now. Thank you, guys. In a few hours I will be leaving to London, I'll be back on Sunday and I will test the patch (hope my server does not crash in the meantime). Thanks! -- Best regards, Luigi mailto:lrosa@mail.hypertrek.info From noreply@sourceforge.net Wed Jul 24 22:19:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jul 2002 14:19:12 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-564587 ] config_list breaks at filter_mime_types Message-ID: Bugs item #564587, was opened at 2002-06-04 21:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=564587&group_id=103 Category: command line scripts Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Devin L. Ganger (dlganger) Assigned to: Nobody/Anonymous (nobody) Summary: config_list breaks at filter_mime_types Initial Comment: When running: config_list -o cpunk.conf cpunk-secpro on my list cpunk-secpro@lists.thecabal.org, I get the following error: (bofh:mailman) /home/mailman $ config_list -o cpunk.conf cpunk-secpro Traceback (most recent call last): File "/home/mailman/bin/config_list", line 268, in ? main() File "/home/mailman/bin/config_list", line 261, in main do_output(listname, outfile) File "/home/mailman/bin/config_list", line 113, in do_output do_list_categories(mlist, k, None, outfp) File "/home/mailman/bin/config_list", line 162, in do_list_categories lines = value.replace('\r', '').split('\n') AttributeError: 'list' object has no attribute 'replace' Doing a tail of the cpunk.conf file show the following: (bofh:mailman) /home/mailman $ tail cpunk.conf # matching MIME major type, e.g. image. Blank lines are ignored. # # After stripping message parts, any multipart attachment that is empty # as a result is removed all together. If the outer part's MIME type # matches one of the strip types, or if all of the outer part's subparts # are stripped, then the whole message is discarded. Finally, each # multipart/alternative section will be replaced by just the first # alternative that is non-empty after the specified types have been # removed. filter_mime_types = ---------------------------------------------------------------------- Comment By: Jay Luker (lbjay) Date: 2002-07-24 21:19 Message: Logged In: YES user_id=51347 I'm experiencing the same problem on a debian (woody) install, python -V = 2.2 I worked around it temporarily by adding a varname != filter_mime_types condition to the "if" on L268. ---------------------------------------------------------------------- Comment By: Devin L. Ganger (dlganger) Date: 2002-06-04 21:08 Message: Logged In: YES user_id=478874 This is on Solaris 7, Python 2.2: (bofh:devin) /home/devin $ python -V Python 2.2 (bofh:devin) /home/devin $ uname -a SunOS bofh.thecabal.internal 5.7 Generic_106541-14 sun4m sparc SUNW,SPARCsystem-600 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=564587&group_id=103 From JasonR.Mastaler Wed Jul 24 23:20:49 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Wed, 24 Jul 2002 16:20:49 -0600 Subject: [Mailman-Developers] Why both a .msg and .db in qfiles? Message-ID: For every incoming message waiting to be posted, MM writes both a .msg file containing the message text, and a .db file containing meta-information about that message. I'm curious why MM doesn't just store the rfc822 headers and message body in the .db pickle/marshal as well? Why maintain two files instead of just one? The reason I ask is because I'm contemplating a similar approach for TMDA. Thanks. -- (http://tmda.net/) From noreply@sourceforge.net Wed Jul 24 23:43:48 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jul 2002 15:43:48 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-564587 ] config_list breaks at filter_mime_types Message-ID: Bugs item #564587, was opened at 2002-06-04 14:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=564587&group_id=103 Category: command line scripts Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Devin L. Ganger (dlganger) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: config_list breaks at filter_mime_types Initial Comment: When running: config_list -o cpunk.conf cpunk-secpro on my list cpunk-secpro@lists.thecabal.org, I get the following error: (bofh:mailman) /home/mailman $ config_list -o cpunk.conf cpunk-secpro Traceback (most recent call last): File "/home/mailman/bin/config_list", line 268, in ? main() File "/home/mailman/bin/config_list", line 261, in main do_output(listname, outfile) File "/home/mailman/bin/config_list", line 113, in do_output do_list_categories(mlist, k, None, outfp) File "/home/mailman/bin/config_list", line 162, in do_list_categories lines = value.replace('\r', '').split('\n') AttributeError: 'list' object has no attribute 'replace' Doing a tail of the cpunk.conf file show the following: (bofh:mailman) /home/mailman $ tail cpunk.conf # matching MIME major type, e.g. image. Blank lines are ignored. # # After stripping message parts, any multipart attachment that is empty # as a result is removed all together. If the outer part's MIME type # matches one of the strip types, or if all of the outer part's subparts # are stripped, then the whole message is discarded. Finally, each # multipart/alternative section will be replaced by just the first # alternative that is non-empty after the specified types have been # removed. filter_mime_types = ---------------------------------------------------------------------- Comment By: Jay Luker (lbjay) Date: 2002-07-24 14:19 Message: Logged In: YES user_id=51347 I'm experiencing the same problem on a debian (woody) install, python -V = 2.2 I worked around it temporarily by adding a varname != filter_mime_types condition to the "if" on L268. ---------------------------------------------------------------------- Comment By: Devin L. Ganger (dlganger) Date: 2002-06-04 14:08 Message: Logged In: YES user_id=478874 This is on Solaris 7, Python 2.2: (bofh:devin) /home/devin $ python -V Python 2.2 (bofh:devin) /home/devin $ uname -a SunOS bofh.thecabal.internal 5.7 Generic_106541-14 sun4m sparc SUNW,SPARCsystem-600 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=564587&group_id=103 From noreply@sourceforge.net Thu Jul 25 00:26:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jul 2002 16:26:12 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-425121 ] Double moderator approval messages Message-ID: Bugs item #425121, was opened at 2001-05-18 10:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=425121&group_id=103 Category: mail delivery Group: 2.0.x Status: Closed Resolution: None Priority: 4 Submitted By: Gert Jan Kruizinga (gjk4all) Assigned to: Thomas Wouters (twouters) Summary: Double moderator approval messages Initial Comment: Dear *, I get the message "Your message to Gein awaits moderator approval" two or three times after posting a message to the mailing list. My moderator also receives his message two or three times, but the two are not related to each other. I already tried to upgrade from mailman-2.0.1 to mailman-2.0.5, but the multiple posting still exists. I have not fount anything regarding this problem in the faq's so i submit it here. Gert Jan Kruizinga. ---------------------------------------------------------------------- Comment By: J. Ros (ros005) Date: 2002-07-25 01:26 Message: Logged In: YES user_id=414801 The problem disapeared after an upgrade of our mail subsystem. This was not a Mailman problem. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-03 20:53 Message: Logged In: YES user_id=12800 Since I haven't heard anything more about this, I'll assume an upgrade fixed your problem. Closing this bug report. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-04-29 00:07 Message: Logged In: YES user_id=12800 Is this bug still a problem for you? If so, first, I would recommend upgrading to MM2.0.10. Second, I'd like to know what version of Python you're using, and also what MTA (and version) you're using. If this is not a problem any more, please follow up so I can close this bug. ---------------------------------------------------------------------- Comment By: J. Ros (ros005) Date: 2002-01-14 15:35 Message: Logged In: YES user_id=414801 Yes, there are two different list admin accounts, but this is not the issue, as also regular users receive more than once. Most of the time I and all other users receive one copy of the mail, but sometimes this can be two, three or even four copies. It seems that mailman works fine most of the time, but sometimes it sends two (or more)copies of the same message. All types of message are affected, not only administrative messages of Mailman to the moderator or users, but also regular posts to members. I will include both message headers for a double message. Futhermore I will include the errors in the mailman log files for these messages. First message 10:02 Received: from sat-relay1.telecom.ptt.nl (sat- relay1.pc.telecom.ptt.nl [10.1.88.11]) by tmail050s.telecom.ptt.nl with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YJKFRJDJ; Fri, 11 Jan 2002 10:02:17 +0100 Received: from hdiro004.kpn.com (hdiro004.kpn.com [145.7.200.4]) by sat-relay1.telecom.ptt.nl (8.11.6/8.11.6) with SMTP id g0B92Kj21854; Fri, 11 Jan 2002 10:02:20 +0100 Received: from 145.7.200.6 by hdiro004.kpn.com (InterScan E- Mail VirusWall NT); Fri, 11 Jan 2002 10:02:20 +0100 Received: from mail.gjk4all.net (mail.gjk4all.net [213.196.2.118]) by relay1.kpn-telecom.nl (8.11.6/8.11.6) with ESMTP id g0B92JX02559; Fri, 11 Jan 2002 10:02:19 +0100 Received: from mail.gjk4all.net (mail.gjk4all.net [213.196.2.118]) by mail.gjk4all.net (Postfix) with ESMTP id BFE827C90; Fri, 11 Jan 2002 10:02:16 +0100 (CET) Received: by mail.gjk4all.net (Postfix, from userid 1011) id EB3D77C8C; Fri, 11 Jan 2002 10:00:28 +0100 (CET) Content-Type: Multipart/Related; boundary="---------- =_1010739627-91125-0" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) To: gein@gjk4all.net Message-Id: <20020111090028.EB3D77C8C@mail.gjk4all.net> From: gein-admin@gjk4all.net Reply-To: gein@gjk4all.net Subject: [Gein] Dagelijkse portie fokke en sukke Sender: gein-admin@gjk4all.net Errors-To: gein-admin@gjk4all.net X-BeenThere: gein@mail.gjk4all.net X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 10:00:28 +0100 (CET) This is a multi-part message in MIME format... ------------=_1010739627-91125-0 Content-Type: Text/HTML Content-Disposition: inline Content-Transfer-Encoding: binary Content-Id: Part-1-20020111@ ------------=_1010739627-91125-0 Content-Type: image/gif; name="fokke_sukke_20020111.gif" Content-Disposition: inline; filename="fokke_sukke_20020111.gif" Content-Transfer-Encoding: base64 Content-Id: Part-2-20020111@ ------------=_1010739627-91125-0-- =========================================== Second message 10:03 Received: from sat-relay1.telecom.ptt.nl (sat- relay1.pc.telecom.ptt.nl [10.1.88.11]) by tmail050s.telecom.ptt.nl with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YJKFRJDY; Fri, 11 Jan 2002 10:02:27 +0100 Received: from hdiro004.kpn.com (hdiro004.kpn.com [145.7.200.4]) by sat-relay1.telecom.ptt.nl (8.11.6/8.11.6) with SMTP id g0B92Uj21921; Fri, 11 Jan 2002 10:02:30 +0100 Received: from 145.7.200.7 by hdiro004.kpn.com (InterScan E- Mail VirusWall NT); Fri, 11 Jan 2002 10:02:30 +0100 Received: from mail.gjk4all.net (mail.gjk4all.net [213.196.2.118]) by relay2.kpn-telecom.nl (8.11.6/8.11.6) with ESMTP id g0B92Tv07835; Fri, 11 Jan 2002 10:02:29 +0100 Received: from mail.gjk4all.net (mail.gjk4all.net [213.196.2.118]) by mail.gjk4all.net (Postfix) with ESMTP id 8C63C7F9A; Fri, 11 Jan 2002 10:02:28 +0100 (CET) Received: by mail.gjk4all.net (Postfix, from userid 1011) id D42257C9A; Fri, 11 Jan 2002 10:00:28 +0100 (CET) Content-Type: Multipart/Related; boundary="---------- =_1010739627-91125-0" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) To: gein@gjk4all.net Message-Id: <20020111090028.D42257C9A@mail.gjk4all.net> From: gein-admin@gjk4all.net Reply-To: gein@gjk4all.net Subject: [Gein] Dagelijkse portie fokke en sukke Sender: gein-admin@gjk4all.net Errors-To: gein-admin@gjk4all.net X-BeenThere: gein@mail.gjk4all.net X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 11 Jan 2002 10:00:28 +0100 (CET) This is a multi-part message in MIME format... ------------=_1010739627-91125-0 Content-Type: Text/HTML Content-Disposition: inline Content-Transfer-Encoding: binary Content-Id: Part-1-20020111@ ------------=_1010739627-91125-0 Content-Type: image/gif; name="fokke_sukke_20020111.gif" Content-Disposition: inline; filename="fokke_sukke_20020111.gif" Content-Transfer-Encoding: base64 Content-Id: Part-2-20020111@ ------------=_1010739627-91125-0-- ==================================== Errors: error:Jan 11 10:02:15 2002 qrunner(91278): Traceback (most recent call last): error:Jan 11 10:02:15 2002 qrunner(91278): File "/usr/local/mailman/Mailman/Archiver/Archiver.py", line 213, in ArchiveMail error:Jan 11 10:02:15 2002 qrunner(91278): self.ExternalArchive(mm_cfg.PUBLIC_EXTERNAL_ARCHIVER, txt) error:Jan 11 10:02:15 2002 qrunner(91278): File "/usr/local/mailman/Mailman/Archiver/Archiver.py", line 174, in ExternalArchive error:Jan 11 10:02:15 2002 qrunner(91278): syslog ('error', 'external archiver non-zero exit status: %d\n' % error:Jan 11 10:02:15 2002 qrunner(91278): TypeError: bad operand type(s) for >> error:Jan 11 10:02:15 2002 (91278) CORRUPT ARCHIVE FOR LIST: gein error:Jan 11 10:02:27 2002 qrunner(91278): Traceback (most recent call last): error:Jan 11 10:02:27 2002 qrunner(91278): File "/usr/local/mailman/Mailman/Archiver/Archiver.py", line 213, in ArchiveMail error:Jan 11 10:02:27 2002 qrunner(91278): self.ExternalArchive(mm_cfg.PUBLIC_EXTERNAL_ARCHIVER, txt) error:Jan 11 10:02:27 2002 qrunner(91278): File "/usr/local/mailman/Mailman/Archiver/Archiver.py", line 174, in ExternalArchive error:Jan 11 10:02:27 2002 qrunner(91278): syslog ('error', 'external archiver non-zero exit status: %d\n' % error:Jan 11 10:02:27 2002 qrunner(91278): TypeError: bad operand type(s) for >> error:Jan 11 10:02:27 2002 (91278) CORRUPT ARCHIVE FOR LIST: gein post:Jan 11 10:02:23 2002 (91278) post to gein from gein- admin@mail.gjk4all.net, size=12424, success post:Jan 11 10:02:36 2002 (91278) post to gein from gein- admin@mail.gjk4all.net, size=12424, success qrunner:Jan 11 10:02:00 2002 (91278) Exception reading qfile: /usr/local/mailman/qfiles/2e3744b0aa565e294e50cc52632 bb41cb439b904 qrunner:Jan 11 10:02:00 2002 (91278) Exception reading qfile: /usr/local/mailman/qfiles/3142c3521506e1863bcab1aaab4 eb9b00b556d90 qrunner:Jan 11 10:02:00 2002 (91278) Exception reading qfile: /usr/local/mailman/qfiles/35bd0398c386c9fa5949935d920 6517d6bff0e35 qrunner:Jan 11 10:02:00 2002 (91278) Exception reading qfile: /usr/local/mailman/qfiles/871f29104cec59a6c8046bc8a9e bf3047fa800b6 qrunner:Jan 11 10:02:00 2002 (91278) Exception reading qfile: /usr/local/mailman/qfiles/c0e97e9812d06e3e9eb47b29f18 1c26da7dbf6cc qrunner:Jan 11 10:02:00 2002 (91278) Exception reading qfile: /usr/local/mailman/qfiles/5f20c0dcd3c3a96ff32df4fe272 52589a93c8cbb qrunner:Jan 11 10:02:00 2002 (91278) Exception reading qfile: /usr/local/mailman/qfiles/e71a75f4429e10b4a8befe6f429 48d0a5f8d4fcd smtp:Jan 11 10:02:20 2002 (91278) smtp for 28 recips, completed in 4.455 seconds smtp:Jan 11 10:02:36 2002 (91278) smtp for 28 recips, completed in 8.968 seconds ---------------------------------------------------------------------- Comment By: J. Ros (ros005) Date: 2001-12-31 19:00 Message: Logged In: YES user_id=414801 Hi, I am the listadmin of gjk4all. We still have the same problem. Messages get sent more than once. This means not only administrative messages of Mailman to the moderator or users, but also regular posts to menmbers. I noticed the same problem on a different mailing list I am subscribed to: http://www.giggleshumor.com The problem seems to be related to the time of day. I hope you can find a solution. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-06-04 20:41 Message: Logged In: YES user_id=12800 In order to debug this, I would need a copy of the all duplicates for one of the duplicated messages. Please include /all/ the original headers, as that's the only way to determine what's going on. My suspicion is that there are multiple qrunners running, and that they aren't getting locked out correctly for some reason. Clearly, we have not seen similar bugs for MM2.0.5 on {python,zope}.org, so I expect it to be a configuration problem. ---------------------------------------------------------------------- Comment By: Gert Jan Kruizinga (gjk4all) Date: 2001-05-29 16:14 Message: Logged In: YES user_id=222418 No, all the users of the list also get the `"your message awaits moderator approval" message twice. Btw i'm not the listadmin, only the server admin, my listadmin also complains that he gets the "messages awaiting moderator approval" message sometimes 2, 3 or even 4 times, but he submitted two email addresses of his own, so that can be explaind. Gert Jan Kruizinga. ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2001-05-29 15:56 Message: Logged In: YES user_id=34209 Are you sure you aren't listed as the list-admin several times ? Do you get each messages that many times ? What about the message headers: can you see where they get 'duplicated' ? (Compare Received: lines and message-id's between the duplicates to find out.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=425121&group_id=103 From claw@kanga.nu Thu Jul 25 03:53:19 2002 From: claw@kanga.nu (J C Lawrence) Date: Wed, 24 Jul 2002 19:53:19 -0700 Subject: [Mailman-Developers] Why both a .msg and .db in qfiles? In-Reply-To: Message from Jason R.Mastaler of "Wed, 24 Jul 2002 16:20:49 MDT." References: Message-ID: <29020.1027565599@kanga.nu> On Wed, 24 Jul 2002 16:20:49 -0600 Jason R Mastaler wrote: > I'm curious why MM doesn't just store the rfc822 headers and message > body in the .db pickle/marshal as well? Why maintain two files > instead of just one? One advantage of the flat text message file is that it can be edited by external tools (in my case XEmacs and various odd scripts) prior to being processed and released for broadcast by the moderation interface. <> > The reason I ask is because I'm contemplating a similar approach for > TMDA. Mailman v2.1 offers a choice between the above approach and a pickle. -- 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 barry@python.org Thu Jul 25 05:55:20 2002 From: barry@python.org (Barry A. Warsaw) Date: Thu, 25 Jul 2002 00:55:20 -0400 Subject: [Mailman-Developers] Why both a .msg and .db in qfiles? References: Message-ID: <15679.33977.475504.590748@anthem.wooz.org> >>>>> "JRM" == Jason R Mastaler writes: JRM> For every incoming message waiting to be posted, MM writes JRM> both a .msg file containing the message text, and a .db file JRM> containing meta-information about that message. JRM> I'm curious why MM doesn't just store the rfc822 headers and JRM> message body in the .db pickle/marshal as well? Why maintain JRM> two files instead of just one? JRM> The reason I ask is because I'm contemplating a similar JRM> approach for TMDA. Mostly historical. When the current arrangement was designed (pre-email package) we had the pickle and a plain text file, so it was convenient to have two separate files. We could probably combine then now except that it's more disruptive than I want for MM2.1. Plus you have to decide whether the metadata will change more often than the message pickle. At one time this was definitely the case, so we could write the (smaller) metadata file quicker and more often than dumping the whole thing out for each change in state. -Barry From noreply@sourceforge.net Thu Jul 25 06:45:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jul 2002 22:45:16 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-571634 ] Date: header field handling Message-ID: Bugs item #571634, was opened at 2002-06-20 09:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=571634&group_id=103 Category: mail delivery Group: 2.1 beta >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Daniel Buchmann (avalon) Assigned to: Nobody/Anonymous (nobody) Summary: Date: header field handling Initial Comment: I got this traceback in my error log (using latest CVS, 2.1b2+): Jun 20 14:58:21 2002 (1991) Traceback (most recent call last): File "/home/mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/home/mailman/Mailman/Queue/Runner.py", line 154, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman/Mailman/Queue/ArchRunner.py", line 54, in _dispose elif abs(now - mktime_tz(tup)) > \ File "/usr/src/build/87651-i386/install/usr/lib/python2.2/rfc822.py", line 955, in mktime_tz t = time.mktime(data[:8] + (0,)) ValueError: year out of range The offending mail was moved to the qfiles/shunt/ directory. A quick dump_db on the .pck file showed this Date: field in the header: Date: Tue, 18 Jun 0102 05:12:09 +0500 The offending mail was a spam mail, so I've deleted the .db and .pck file. But reporting it anyway. :) ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-25 01:45 Message: Logged In: YES user_id=12800 Fixed. The occurrance of this exception is a pretty good indication that the date needs to be clobbered. ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=571634&group_id=103 From barry@python.org Thu Jul 25 06:49:40 2002 From: barry@python.org (Barry A. Warsaw) Date: Thu, 25 Jul 2002 01:49:40 -0400 Subject: [Mailman-Developers] 2.1b2-production ready? References: <200207231706.31857.laurence@digitalpulp.com> <15678.12391.192915.737145@anthem.wooz.org> <1027493378.2277.20.camel@fornax.bibsys.no> Message-ID: <15679.37236.383117.88251@anthem.wooz.org> >>>>> "DB" == Daniel Buchmann writes: DB> also have a bunch of errors in logs/error... :-/ They are DB> mostly "ValueError: year out of range" errors (see bug DB> #571634). I also have a few "AlreadyLockedError"s: Fixed, and fixed. DB> And a couple of web tracebacks, too lengthy to dump here, let DB> me know if you want 'em. ;) Not if they're related to this bug. CVS should be fixed now. >> I will likely release another beta sometime this week or by the >> weekend. At that point I'll feel good enough about it to >> migrate the rest of the mailman-* lists over to it. DB> Ok, would be nice if you could weed through the bug reports on DB> SF.net and maybe fix some of them before you release a new DB> beta, though.. (Which would probably give me time to catch up DB> on the norwegian translation... ;) Better hurry! :) I'm working my way through them as other responsibilities this week permit. But I'm going to try very hard to get a new beta out. I'm below the magic "50" open bugs threshold. and-no-that-doesn't-mean-you-should-submit-more-bugs-ly y'rs, -Barry :) From noreply@sourceforge.net Thu Jul 25 06:55:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 24 Jul 2002 22:55:41 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-584989 ] bounced large messages are deleted! Message-ID: Bugs item #584989, was opened at 2002-07-22 12:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584989&group_id=103 Category: mail delivery Group: 2.1 beta >Status: Open Resolution: Fixed Priority: 5 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) Summary: bounced large messages are deleted! Initial Comment: I`m using 2.1b2+ (July, 22th) and if a message is larger than the maximum allowd size (of this list) it is not bounced or hold for approval succesfully. The message disappears and mailman crashes. Maybe it`s just a mistake in the translation in german mailman.po? Jul 22 17:36:55 2002 (28610) Uncaught runner exception: an integer is required Jul 22 17:36:55 2002 (28610) Traceback (most recent call last): File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 154, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 129, in _dispose status = self._dopipeline(mlist, msg, msgdata, pipeline) File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 152, in _dopipel sys.modules[modname].process(mlist, msg, msgdata) File "/usr/lib/mailman/Mailman/Handlers/Hold.py", line 179, in process MessageTooBig(bodylen, mlist.max_message_size)) File "/usr/lib/mailman/Mailman/Handlers/Hold.py", line 198, in hold_for_approv reason = Utils.wrap(exc.reason_notice()) File "/usr/lib/mailman/Mailman/Handlers/Hold.py", line 103, in reason_notice return _('''Message body is too big: %(size)d bytes with a limit of File "/usr/lib/mailman/Mailman/i18n.py", line 76, in _ return _translation.gettext(s) % dict TypeError: an integer is required ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-25 01:55 Message: Logged In: YES user_id=12800 There appears to be a bug in the bundled Japanese codec package, such that japanese.pth is still installed in site-packages even though we're trying hard to force it to not do this. I'm reopening this bug and trying to find out if we can either get a working japanese code package, or a workaround for Mailman. In the meantime, you'll need to manually remove /usr/lib/python2.2/site-packages/japanese.pth ---------------------------------------------------------------------- Comment By: Peer Heinlein (pheinlein) Date: 2002-07-24 12:24 Message: Logged In: YES user_id=581680 I really don`t know how python works and how to help myself. Maybe something has changed - I installed the package python-devel and python tk. There`s a traceback when I start "python -v": [...] # /usr/lib/python2.2/stat.pyc matches /usr/lib/python2.2/stat.py import stat # precompiled from /usr/lib/python2.2/stat.pyc # /usr/lib/python2.2/UserDict.pyc matches /usr/lib/python2.2/UserDict.py import UserDict # precompiled from /usr/lib/python2.2/UserDict.pyc 'import site' failed; traceback: Traceback (most recent call last): File "/var/tmp/python-2.2-build//usr/lib/python2.2/site.py", line 177, in ? addsitedir(sitedir) File "/var/tmp/python-2.2-build//usr/lib/python2.2/site.py", line 128, in addsitedir addpackage(sitedir, name) File "/var/tmp/python-2.2-build//usr/lib/python2.2/site.py", line 151, in addpackage exec dir File "", line 1, in ? ImportError: No module named japanese Python 2.2 (#1, Mar 26 2002, 15:46:04) [GCC 2.95.3 20010315 (SuSE)] on linux2 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 09:26 Message: Logged In: YES user_id=12800 Something may have changed in your Python environment? I don't see how that fix could have had anything to do with it! ---------------------------------------------------------------------- Comment By: Peer Heinlein (pheinlein) Date: 2002-07-24 04:14 Message: Logged In: YES user_id=581680 It looks like it works. -Thanks! But now I`m getting the message "`import site` failed; use -v to traceback"?! Peer ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 01:06 Message: Logged In: YES user_id=12800 It does look like it's a bug in the German translation for that message. I'm about to commit a fix to the German catalog; can you try doing a cvs update and see if that fixes your problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584989&group_id=103 From noreply@sourceforge.net Thu Jul 25 09:59:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jul 2002 01:59:30 -0700 Subject: [Mailman-Developers] [ mailman-Patches-534577 ] Add SpamAssassin filter to mail pipeline Message-ID: Patches item #534577, was opened at 2002-03-25 16:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=534577&group_id=103 Category: list administration Group: Mailman 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: Add SpamAssassin filter to mail pipeline Initial Comment: This filter adds support for discarding or holding spam sent to the mailing list. It contacts a spamd daemon (from SpamAssassin -- http://spamassassin.taint.org) to score the message. If the score is above a certain threshold (default 10), the message is discarded and an entry is written to the vette log. If the score is above another lower threshold (default 5), the message is held for moderation. The SpamAssassin.py file should be installed in Mailman/Handlers/. The LIST_PIPELINE variable in Mailman/Handlers/HandlerAPI.py should be modified to include a 'SpamAssassin' item (I put it just after the existing 'SpamDetect' item). To change the defaults, the following can be added to the mm_cfg.py file: SPAMASSASSIN_HOST = 'host:port' # how to contact SA SPAMASSASSIN_DISCARD_SCORE = 10 SPAMASSASSIN_HOLD_SCORE = 5 If you don't want to discard messages, then DISCARD_SCORE can be set to something very high (1000 should do it). It looks the MM2.1 filter APIs have changed a bit, so this filter will need some modifications to work with that version. When I get round to upgrading, I might look into updating it. ---------------------------------------------------------------------- >Comment By: James Henstridge (jhenstridge) Date: 2002-07-25 16:59 Message: Logged In: YES user_id=146903 Yet another new version that fixes a small typo. With previous messages, you couldn't approve messages that had been identified as spam once (they would get identified again when the queue got processed, instead of passing the message through). ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-07-10 08:19 Message: Logged In: YES user_id=146903 The Mailman installation on mail.gnome.org also uses this filter. I don't think there are any stability problems with the filter. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2002-07-10 05:16 Message: Logged In: YES user_id=81797 FYI, I ran the previous version since installation and it seemed to work fine. I didn't run into any problems, with probably 500 messages handled. I've updated to the new version and it seems ok so far, but I've only sent about 10 messages through. Sean ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-07-03 12:02 Message: Logged In: YES user_id=146903 Yet another version. There were some bugs in handling of certain error conditions when talking to spamd. These would result in exceptions and the messages staying in the delivery queue :( With the new version, the message will be passed through unchecked under these conditions, and a message will be added to the error log. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2002-06-13 05:48 Message: Logged In: YES user_id=81797 FYI: I've been running the 2002-05-14 version of this patch with spamassassin 2.20 for the last day on our main mailman box and it seems to be working great. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-05-14 14:04 Message: Logged In: YES user_id=146903 This version is essentially the same as the previous version, but adds compatibility with python > 1.5.2, which doesn't like you passing two arguments to socket.connect(). ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-04-27 14:17 Message: Logged In: YES user_id=146903 Just attached my updated version of the patch. This version requires SpamAssassin 2.20 (for the extra commands that the spamd daemon understands). It now displays a list of which rules were triggered for held messages, and can give messages from list members a bonus (defaults to 2), so that they are less likely to get held as spam. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-03-26 09:21 Message: Logged In: YES user_id=146903 There is a fairly easy optimisation for this filter that I missed when writing it. It calls str() on the message object twice. It would be quicker to call str() on the message once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=534577&group_id=103 From noreply@sourceforge.net Thu Jul 25 10:00:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jul 2002 02:00:27 -0700 Subject: [Mailman-Developers] [ mailman-Patches-534577 ] Add SpamAssassin filter to mail pipeline Message-ID: Patches item #534577, was opened at 2002-03-25 16:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=534577&group_id=103 Category: list administration Group: Mailman 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: Add SpamAssassin filter to mail pipeline Initial Comment: This filter adds support for discarding or holding spam sent to the mailing list. It contacts a spamd daemon (from SpamAssassin -- http://spamassassin.taint.org) to score the message. If the score is above a certain threshold (default 10), the message is discarded and an entry is written to the vette log. If the score is above another lower threshold (default 5), the message is held for moderation. The SpamAssassin.py file should be installed in Mailman/Handlers/. The LIST_PIPELINE variable in Mailman/Handlers/HandlerAPI.py should be modified to include a 'SpamAssassin' item (I put it just after the existing 'SpamDetect' item). To change the defaults, the following can be added to the mm_cfg.py file: SPAMASSASSIN_HOST = 'host:port' # how to contact SA SPAMASSASSIN_DISCARD_SCORE = 10 SPAMASSASSIN_HOLD_SCORE = 5 If you don't want to discard messages, then DISCARD_SCORE can be set to something very high (1000 should do it). It looks the MM2.1 filter APIs have changed a bit, so this filter will need some modifications to work with that version. When I get round to upgrading, I might look into updating it. ---------------------------------------------------------------------- >Comment By: James Henstridge (jhenstridge) Date: 2002-07-25 17:00 Message: Logged In: YES user_id=146903 remembering to check the "upload file" checkbox this time ... ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-07-25 16:59 Message: Logged In: YES user_id=146903 Yet another new version that fixes a small typo. With previous messages, you couldn't approve messages that had been identified as spam once (they would get identified again when the queue got processed, instead of passing the message through). ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-07-10 08:19 Message: Logged In: YES user_id=146903 The Mailman installation on mail.gnome.org also uses this filter. I don't think there are any stability problems with the filter. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2002-07-10 05:16 Message: Logged In: YES user_id=81797 FYI, I ran the previous version since installation and it seemed to work fine. I didn't run into any problems, with probably 500 messages handled. I've updated to the new version and it seems ok so far, but I've only sent about 10 messages through. Sean ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-07-03 12:02 Message: Logged In: YES user_id=146903 Yet another version. There were some bugs in handling of certain error conditions when talking to spamd. These would result in exceptions and the messages staying in the delivery queue :( With the new version, the message will be passed through unchecked under these conditions, and a message will be added to the error log. ---------------------------------------------------------------------- Comment By: Sean Reifschneider (jafo) Date: 2002-06-13 05:48 Message: Logged In: YES user_id=81797 FYI: I've been running the 2002-05-14 version of this patch with spamassassin 2.20 for the last day on our main mailman box and it seems to be working great. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-05-14 14:04 Message: Logged In: YES user_id=146903 This version is essentially the same as the previous version, but adds compatibility with python > 1.5.2, which doesn't like you passing two arguments to socket.connect(). ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-04-27 14:17 Message: Logged In: YES user_id=146903 Just attached my updated version of the patch. This version requires SpamAssassin 2.20 (for the extra commands that the spamd daemon understands). It now displays a list of which rules were triggered for held messages, and can give messages from list members a bonus (defaults to 2), so that they are less likely to get held as spam. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2002-03-26 09:21 Message: Logged In: YES user_id=146903 There is a fairly easy optimisation for this filter that I missed when writing it. It calls str() on the message object twice. It would be quicker to call str() on the message once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=534577&group_id=103 From noreply@sourceforge.net Thu Jul 25 14:25:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jul 2002 06:25:47 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-584989 ] bounced large messages are deleted! Message-ID: Bugs item #584989, was opened at 2002-07-22 12:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584989&group_id=103 Category: mail delivery Group: 2.1 beta >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Peer Heinlein (pheinlein) Assigned to: Nobody/Anonymous (nobody) Summary: bounced large messages are deleted! Initial Comment: I`m using 2.1b2+ (July, 22th) and if a message is larger than the maximum allowd size (of this list) it is not bounced or hold for approval succesfully. The message disappears and mailman crashes. Maybe it`s just a mistake in the translation in german mailman.po? Jul 22 17:36:55 2002 (28610) Uncaught runner exception: an integer is required Jul 22 17:36:55 2002 (28610) Traceback (most recent call last): File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 154, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 129, in _dispose status = self._dopipeline(mlist, msg, msgdata, pipeline) File "/usr/lib/mailman/Mailman/Queue/IncomingRunner.py", line 152, in _dopipel sys.modules[modname].process(mlist, msg, msgdata) File "/usr/lib/mailman/Mailman/Handlers/Hold.py", line 179, in process MessageTooBig(bodylen, mlist.max_message_size)) File "/usr/lib/mailman/Mailman/Handlers/Hold.py", line 198, in hold_for_approv reason = Utils.wrap(exc.reason_notice()) File "/usr/lib/mailman/Mailman/Handlers/Hold.py", line 103, in reason_notice return _('''Message body is too big: %(size)d bytes with a limit of File "/usr/lib/mailman/Mailman/i18n.py", line 76, in _ return _translation.gettext(s) % dict TypeError: an integer is required ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-25 09:25 Message: Logged In: YES user_id=12800 I just committed a fix to misc/Makefile.in which should stop japanese.pth from being installed in your system site-packages. You'll need to re-run configure (or config.status) to have this take effect, and you'll need to manually remove japanese.pth to fix your system. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-25 01:55 Message: Logged In: YES user_id=12800 There appears to be a bug in the bundled Japanese codec package, such that japanese.pth is still installed in site-packages even though we're trying hard to force it to not do this. I'm reopening this bug and trying to find out if we can either get a working japanese code package, or a workaround for Mailman. In the meantime, you'll need to manually remove /usr/lib/python2.2/site-packages/japanese.pth ---------------------------------------------------------------------- Comment By: Peer Heinlein (pheinlein) Date: 2002-07-24 12:24 Message: Logged In: YES user_id=581680 I really don`t know how python works and how to help myself. Maybe something has changed - I installed the package python-devel and python tk. There`s a traceback when I start "python -v": [...] # /usr/lib/python2.2/stat.pyc matches /usr/lib/python2.2/stat.py import stat # precompiled from /usr/lib/python2.2/stat.pyc # /usr/lib/python2.2/UserDict.pyc matches /usr/lib/python2.2/UserDict.py import UserDict # precompiled from /usr/lib/python2.2/UserDict.pyc 'import site' failed; traceback: Traceback (most recent call last): File "/var/tmp/python-2.2-build//usr/lib/python2.2/site.py", line 177, in ? addsitedir(sitedir) File "/var/tmp/python-2.2-build//usr/lib/python2.2/site.py", line 128, in addsitedir addpackage(sitedir, name) File "/var/tmp/python-2.2-build//usr/lib/python2.2/site.py", line 151, in addpackage exec dir File "", line 1, in ? ImportError: No module named japanese Python 2.2 (#1, Mar 26 2002, 15:46:04) [GCC 2.95.3 20010315 (SuSE)] on linux2 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 09:26 Message: Logged In: YES user_id=12800 Something may have changed in your Python environment? I don't see how that fix could have had anything to do with it! ---------------------------------------------------------------------- Comment By: Peer Heinlein (pheinlein) Date: 2002-07-24 04:14 Message: Logged In: YES user_id=581680 It looks like it works. -Thanks! But now I`m getting the message "`import site` failed; use -v to traceback"?! Peer ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 01:06 Message: Logged In: YES user_id=12800 It does look like it's a bug in the German translation for that message. I'm about to commit a fix to the German catalog; can you try doing a cvs update and see if that fixes your problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=584989&group_id=103 From noreply@sourceforge.net Thu Jul 25 15:10:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jul 2002 07:10:37 -0700 Subject: [Mailman-Developers] [ mailman-Patches-444884 ] Integration of Mailman & htdig for archi Message-ID: Patches item #444884, was opened at 2001-07-26 18:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444884&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Barrett (ppsys) Assigned to: Nobody/Anonymous (nobody) Summary: Integration of Mailman & htdig for archi Initial Comment: This patch is applicable to Mailman 2.0.6 release that has had search enhancement patch 444879 patch installed - if your Defaults.py has the ARCHIVE_INDEXING_ENABLE and ARCHIVE_INDEXING_DISABLE in it then you've got that patch. It replaces earlier patches 401670 and 402423 and is mainly to correct some problems arising from fixes introduced into Mailman by bug fix releases since the 402423 patch. This patch integrates htdig with Mailman and provides: 1. per list search facility with a search form on the list's TOC page. 2. maintenance of privacy of private archives which requires the user to establish their credentials via the normal private archive access before any access via htdig is allowed. 3. a common base URL for both public and private archive access via htsearch results so that htdig indices are unaffected by changingan archive from private to public and vice versa. All access to archives via htdig is controlled by a new wrapped cgi- bin script called htdig.py. 4. a new cron activated script and extra crontab entry which runs htdig regularly to maintain the per list search indices. 5. automatic creation, deletion and maintenance of htdig configuration files and such. Beyond installing htdig and telling Mailman where it is via mm_cfg you do not have to do any other setup. Well not quite you do have to set up a single per installation symlink to allow htdig to find the automatically generated per list htdig configuration files. You probably want to run this patch as follows: cd patch -p1 < ---------------------------------------------------------------------- >Comment By: Richard Barrett (ppsys) Date: 2002-07-25 14:10 Message: Logged In: YES user_id=75166 htdig-2.0.12-0.1.patch is a revised version of the patch that applies without complaint to MM 2.0.12. It also add a facility for adding site wide htdig configuration attributes to all list specific htdig configuration files. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-05-23 09:59 Message: Logged In: YES user_id=75166 htdig-2.0.11-0.1.patch is a revised version of the patch that is compatible with MM 2.0.11 This version removes an incompatibility with Python 2.2 which caused warning messages to be generated when any of the family cron/nightly_htdig scripts were run. Some guidance on file access permissions for some htdig database files needed by rundig have been added to installation notes. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-19 10:59 Message: Logged In: YES user_id=75166 htdig-2.0.10-0.1.patch is a revised version of the patch that is compatible with MM 2.0.10 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-08 17:46 Message: Logged In: YES user_id=75166 htdig-2.0.9-0.1.patch is a revised version of the patch that is compatible with MM 2.0.9 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-03-06 16:22 Message: Logged In: YES user_id=75166 htdig-2.1cvs-20020306.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 12:30 GMT 6 Mar 2002 Known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-17 16:56 Message: Logged In: YES user_id=75166 htdig-2.1cvs-20011217.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 11:50 GMT 17 Dec 2001 The only known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-13 16:58 Message: Logged In: YES user_id=75166 htdig-2.1a3-0.1.patch is a revised version of the patch that is compatible with the code published in mailman-2.1a3.tgz on sourceforge. The only known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 17:33 Message: Logged In: YES user_id=75166 The htdig-2.0.8-0.1.patch version of the patch resolves a problem that can arise with htdig indexing if the web_page_url for a list uses other than the http addressing (some folks want to use https). While specified as for MM 2.0.8 the revised patch should work OK with 2.0.7, 2.0.6 and probably back as far as 2.0.3. If you do not have the requirement for using other than http addressing in you lists web_page_urls it probably isn't worth the trouble of upgrading to this patch level. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 11:08 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.8 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-27 12:00 Message: Logged In: YES user_id=75166 This patch should also apply without problems to Mm 2.0.7 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-09 11:54 Message: Logged In: YES user_id=75166 The htdig-2.0.6-03.patch version of the patch makes some previously hard-coded things configurable and enhances the capability to run the htdig searches and indexing on a different machine to the one delivering Mailman and Mailman's web UI. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444884&group_id=103 From noreply@sourceforge.net Thu Jul 25 15:11:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jul 2002 07:11:54 -0700 Subject: [Mailman-Developers] [ mailman-Patches-444879 ] Archive indexer control to improve index Message-ID: Patches item #444879, was opened at 2001-07-26 18:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444879&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Barrett (ppsys) Assigned to: Nobody/Anonymous (nobody) Summary: Archive indexer control to improve index Initial Comment: This patch is applicable to Mailman 2.0.6 release and supercedes ealier patches 401669 and 402422. This patch should improve the quality of search results returned by search engines such as htdig (http://www.htdig.org) where the seach engine's index builder responds to strings embedded in the html pages that are the subject of the indexing. The changes in this patch: 1. allow strings for enabling and disabling indexing to be defined in mm_cfg.py. 2. embeds those strings in the pages generated as the html version of a list's archive. By default nothing in the html changes. To get the desired effect, you must define ARCHIVE_INDEXING_ENABLE and ARCHIVE_INDEXING_DISABLE in mm_cfg.py You probably want to run this patch as follows: cd patch -p1 < See also the associated patch for integrating the htdig search software with mailman's internal archiver ouput. ---------------------------------------------------------------------- >Comment By: Richard Barrett (ppsys) Date: 2002-07-25 14:11 Message: Logged In: YES user_id=75166 indexing-2.0.11-0.1.patch should apply without problems to MM 2.0.12 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-05-23 09:50 Message: Logged In: YES user_id=75166 indexing-2.0.11-0.1.patch is a revised version of the patch that is compatible with MM 2.0.11 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-19 10:53 Message: Logged In: YES user_id=75166 indexing-2.0.9-0.1.patch should apply without problems to MM 2.0.10 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-08 17:43 Message: Logged In: YES user_id=75166 indexing-2.0.9-0.1.patch is a revised version of the patch that is compatible with MM 2.0.9 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-03-06 16:14 Message: Logged In: YES user_id=75166 indexing-2.1cvs-20020306.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 12:30 GMT 6 Mar 2002. Corrects problem noted or 5 Mar 2002 by nobody ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-03-05 21:41 Message: Logged In: NO When applying this patch I get an error with Hunk 1 and Defaults.py is not updated. This happens with the a clean download of the latest cvs installation (5 Mar 2002). Any ideas what the problem is? ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-17 16:53 Message: Logged In: YES user_id=75166 indexing-2.1cvs-20011217.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 11:50 GMT 17 Dec 2001 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-13 16:48 Message: Logged In: YES user_id=75166 indexing-2.1a3-0.1.patch is a revised version of the patch that is compatible with the code published in mailman-2.1a3.tgz on sourceforge. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 11:07 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.8 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-27 12:03 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.7 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444879&group_id=103 From noreply@sourceforge.net Thu Jul 25 16:07:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jul 2002 08:07:42 -0700 Subject: [Mailman-Developers] [ mailman-Patches-444884 ] Integration of Mailman & htdig for archi Message-ID: Patches item #444884, was opened at 2001-07-26 18:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444884&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Barrett (ppsys) Assigned to: Nobody/Anonymous (nobody) Summary: Integration of Mailman & htdig for archi Initial Comment: This patch is applicable to Mailman 2.0.6 release that has had search enhancement patch 444879 patch installed - if your Defaults.py has the ARCHIVE_INDEXING_ENABLE and ARCHIVE_INDEXING_DISABLE in it then you've got that patch. It replaces earlier patches 401670 and 402423 and is mainly to correct some problems arising from fixes introduced into Mailman by bug fix releases since the 402423 patch. This patch integrates htdig with Mailman and provides: 1. per list search facility with a search form on the list's TOC page. 2. maintenance of privacy of private archives which requires the user to establish their credentials via the normal private archive access before any access via htdig is allowed. 3. a common base URL for both public and private archive access via htsearch results so that htdig indices are unaffected by changingan archive from private to public and vice versa. All access to archives via htdig is controlled by a new wrapped cgi- bin script called htdig.py. 4. a new cron activated script and extra crontab entry which runs htdig regularly to maintain the per list search indices. 5. automatic creation, deletion and maintenance of htdig configuration files and such. Beyond installing htdig and telling Mailman where it is via mm_cfg you do not have to do any other setup. Well not quite you do have to set up a single per installation symlink to allow htdig to find the automatically generated per list htdig configuration files. You probably want to run this patch as follows: cd patch -p1 < ---------------------------------------------------------------------- >Comment By: Richard Barrett (ppsys) Date: 2002-07-25 15:07 Message: Logged In: YES user_id=75166 Do not use htdig-2.0.12-0.1.patch there is an error in it. Use htdig-2.0.12-0.2.patch instead ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-25 14:10 Message: Logged In: YES user_id=75166 htdig-2.0.12-0.1.patch is a revised version of the patch that applies without complaint to MM 2.0.12. It also add a facility for adding site wide htdig configuration attributes to all list specific htdig configuration files. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-05-23 09:59 Message: Logged In: YES user_id=75166 htdig-2.0.11-0.1.patch is a revised version of the patch that is compatible with MM 2.0.11 This version removes an incompatibility with Python 2.2 which caused warning messages to be generated when any of the family cron/nightly_htdig scripts were run. Some guidance on file access permissions for some htdig database files needed by rundig have been added to installation notes. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-19 10:59 Message: Logged In: YES user_id=75166 htdig-2.0.10-0.1.patch is a revised version of the patch that is compatible with MM 2.0.10 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-08 17:46 Message: Logged In: YES user_id=75166 htdig-2.0.9-0.1.patch is a revised version of the patch that is compatible with MM 2.0.9 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-03-06 16:22 Message: Logged In: YES user_id=75166 htdig-2.1cvs-20020306.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 12:30 GMT 6 Mar 2002 Known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-17 16:56 Message: Logged In: YES user_id=75166 htdig-2.1cvs-20011217.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 11:50 GMT 17 Dec 2001 The only known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-13 16:58 Message: Logged In: YES user_id=75166 htdig-2.1a3-0.1.patch is a revised version of the patch that is compatible with the code published in mailman-2.1a3.tgz on sourceforge. The only known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 17:33 Message: Logged In: YES user_id=75166 The htdig-2.0.8-0.1.patch version of the patch resolves a problem that can arise with htdig indexing if the web_page_url for a list uses other than the http addressing (some folks want to use https). While specified as for MM 2.0.8 the revised patch should work OK with 2.0.7, 2.0.6 and probably back as far as 2.0.3. If you do not have the requirement for using other than http addressing in you lists web_page_urls it probably isn't worth the trouble of upgrading to this patch level. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 11:08 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.8 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-27 12:00 Message: Logged In: YES user_id=75166 This patch should also apply without problems to Mm 2.0.7 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-09 11:54 Message: Logged In: YES user_id=75166 The htdig-2.0.6-03.patch version of the patch makes some previously hard-coded things configurable and enhances the capability to run the htdig searches and indexing on a different machine to the one delivering Mailman and Mailman's web UI. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444884&group_id=103 From noreply@sourceforge.net Thu Jul 25 16:51:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jul 2002 08:51:49 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-586526 ] No way to set default FQDN. Message-ID: Bugs item #586526, was opened at 2002-07-25 09:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=586526&group_id=103 Category: configuring/installing Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dylan Griffiths (inoshiro) Assigned to: Nobody/Anonymous (nobody) Summary: No way to set default FQDN. Initial Comment: If you configure Mailmain on a machine with multiple IFs, and the first is an internal name (the second being the internet one), Mailman will configure itself for the INTERNAL domain and use this in mailings everywhere (unless overriden by the mailing list admin). There is NO WAY to specify which FQDN to use by default in the configure path, because the --host= is IGNORED and no other option exists which is remotely similar. PLEASE either make your configure script honour the --host= variable (best case), or document a method for setting a system-wide default FQDN which is not the one that configure finds. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=586526&group_id=103 From noreply@sourceforge.net Thu Jul 25 17:00:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jul 2002 09:00:46 -0700 Subject: [Mailman-Developers] [ mailman-Patches-585643 ] Mailman 2.0.13 candidate patch Message-ID: Patches item #585643, was opened at 2002-07-23 15:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=585643&group_id=103 Category: None Group: Mailman 2.0.x Status: Open Resolution: None Priority: 8 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Mailman 2.0.13 candidate patch Initial Comment: Mailman 2.0.12 had compatibility problems with Python 1.5.2. This patch fixes these AFAICT, and a few other small bugs that have cropped up. Note that this is a candidate patch. The actual MM2.0.13 patch may be different. However I would really appreciate folks using Mailman 2.0.12 (especially if you're using Python 1.5.2) to give this patch a try and see if it fixes your problems. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-07-25 09:00 Message: Logged In: NO This fixed the problems I'd been having on my Solaris 8 box running Mailman 2.0.12 and Python 1.52. Thanks much. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=585643&group_id=103 From noreply@sourceforge.net Thu Jul 25 17:13:16 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jul 2002 09:13:16 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-586526 ] No way to set default FQDN. Message-ID: Bugs item #586526, was opened at 2002-07-25 11:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=586526&group_id=103 Category: configuring/installing >Group: 2.1 beta >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Dylan Griffiths (inoshiro) Assigned to: Nobody/Anonymous (nobody) Summary: No way to set default FQDN. Initial Comment: If you configure Mailmain on a machine with multiple IFs, and the first is an internal name (the second being the internet one), Mailman will configure itself for the INTERNAL domain and use this in mailings everywhere (unless overriden by the mailing list admin). There is NO WAY to specify which FQDN to use by default in the configure path, because the --host= is IGNORED and no other option exists which is remotely similar. PLEASE either make your configure script honour the --host= variable (best case), or document a method for setting a system-wide default FQDN which is not the one that configure finds. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-25 12:13 Message: Logged In: YES user_id=12800 See the --with-urlhost and --with-mailhost configure options in MM2.1 cvs, which will be in the next beta release, likely some time this weekend. In the meantime, it's fairly easy to simply edit the mm_cfg.py file for the correct values after doing a make install. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=586526&group_id=103 From JasonR.Mastaler Thu Jul 25 17:25:50 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Thu, 25 Jul 2002 10:25:50 -0600 Subject: [Mailman-Developers] Re: Why both a .msg and .db in qfiles? References: <15679.33977.475504.590748@anthem.wooz.org> Message-ID: barry@python.org (Barry A. Warsaw) writes: > Mostly historical. When the current arrangement was designed > (pre-email package) we had the pickle and a plain text file, so it > was convenient to have two separate files. We could probably > combine then now except that it's more disruptive than I want for > MM2.1. Plus you have to decide whether the metadata will change > more often than the message pickle. At one time this was definitely > the case, so we could write the (smaller) metadata file quicker and > more often than dumping the whole thing out for each change in > state. I'm confused. Currently, MM has a plain text file containing the message headers/body and a marshal containing the metadata. Are you saying that previously, the metadata was contained in the text file, and the message headers/body in a pickle? -- (http://tmda.net/) From JasonR.Mastaler Thu Jul 25 17:10:58 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Thu, 25 Jul 2002 10:10:58 -0600 Subject: [Mailman-Developers] Re: Why both a .msg and .db in qfiles? References: <29020.1027565599@kanga.nu> Message-ID: J C Lawrence writes: > Mailman v2.1 offers a choice between the above approach and a > pickle. Where is this configured in MM 2.1? -- (http://tmda.net/) From barry@python.org Thu Jul 25 17:30:30 2002 From: barry@python.org (Barry A. Warsaw) Date: Thu, 25 Jul 2002 12:30:30 -0400 Subject: [Mailman-Developers] Re: Why both a .msg and .db in qfiles? References: <15679.33977.475504.590748@anthem.wooz.org> Message-ID: <15680.10150.636780.321804@anthem.wooz.org> >>>>> "JRM" == Jason R Mastaler writes: JRM> I'm confused. Currently, MM has a plain text file containing JRM> the message headers/body and a marshal containing the JRM> metadata. JRM> Are you saying that previously, the metadata was contained in JRM> the text file, and the message headers/body in a pickle? "Current" is a relative term. :) Sticking to MM2.1, when the message first comes in from the MTA, it's dumped into qfiles/in as a pickle file of the metadata and a plaintext message file (header + body). When the incoming qrunner first parses it, and if the message ever gets re-queued (regardless of target queue directory), it will (by default) write it out again as a metadata pickle file and a pickle file of the parsed message object tree. -Barry From claw@kanga.nu Thu Jul 25 17:35:18 2002 From: claw@kanga.nu (J C Lawrence) Date: Thu, 25 Jul 2002 09:35:18 -0700 Subject: [Mailman-Developers] Re: Why both a .msg and .db in qfiles? In-Reply-To: Message from Jason R.Mastaler of "Thu, 25 Jul 2002 10:10:58 MDT." References: <29020.1027565599@kanga.nu> Message-ID: <4517.1027614918@kanga.nu> On Thu, 25 Jul 2002 10:10:58 -0600 Jason R Mastaler wrote: > J C Lawrence writes: >> Mailman v2.1 offers a choice between the above approach and a pickle. > Where is this configured in MM 2.1? Defaults.py/mm_cfg.py. -- 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 barry@python.org Thu Jul 25 17:36:58 2002 From: barry@python.org (Barry A. Warsaw) Date: Thu, 25 Jul 2002 12:36:58 -0400 Subject: [Mailman-Developers] Re: Why both a .msg and .db in qfiles? References: <29020.1027565599@kanga.nu> Message-ID: <15680.10538.703065.588561@anthem.wooz.org> >>>>> "JRM" == Jason R Mastaler writes: >> Mailman v2.1 offers a choice between the above approach and a >> pickle. JRM> Where is this configured in MM 2.1? See SAVE_MSGS_AS_PICKLES in Mailman/Queue/Switchboard.py for whether re-queued messages get stored as a pickle or as plaintext. See METADATA_FORMAT in Defaults.py/mm_cfg.py for the storage format for the metadata dictionary (I was mistaken that it's always a pickle, in fact it's usually a marshal, and METADATA_FORMAT=METAFMT_MARSHAL is probably the only one that works, see SF patch #567288). -Barry From JasonR.Mastaler Thu Jul 25 17:49:14 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Thu, 25 Jul 2002 10:49:14 -0600 Subject: [Mailman-Developers] Re: Why both a .msg and .db in qfiles? References: <29020.1027565599@kanga.nu> <4517.1027614918@kanga.nu> Message-ID: J C Lawrence writes: >> Where is this configured in MM 2.1? > > Defaults.py/mm_cfg.py. Gee, thanks. -- (http://tmda.net/) From JasonR.Mastaler Thu Jul 25 18:13:39 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Thu, 25 Jul 2002 11:13:39 -0600 Subject: [Mailman-Developers] Re: Why both a .msg and .db in qfiles? References: <29020.1027565599@kanga.nu> <15680.10538.703065.588561@anthem.wooz.org> Message-ID: barry@python.org (Barry A. Warsaw) writes: > See METADATA_FORMAT in Defaults.py/mm_cfg.py for the storage format > for the metadata dictionary (I was mistaken that it's always a > pickle, in fact it's usually a marshal And why use a marshal instead of a pickle? Better performance? -- (http://tmda.net/) From barry@python.org Thu Jul 25 19:57:01 2002 From: barry@python.org (Barry A. Warsaw) Date: Thu, 25 Jul 2002 14:57:01 -0400 Subject: [Mailman-Developers] Re: Why both a .msg and .db in qfiles? References: <29020.1027565599@kanga.nu> <15680.10538.703065.588561@anthem.wooz.org> Message-ID: <15680.18941.243085.925884@anthem.wooz.org> >>>>> "JRM" == Jason R Mastaler writes: >> See METADATA_FORMAT in Defaults.py/mm_cfg.py for the storage >> format for the metadata dictionary (I was mistaken that it's >> always a pickle, in fact it's usually a marshal JRM> And why use a marshal instead of a pickle? Better JRM> performance? For something as simple as a dictionary (which the metadata is), I believe so. I did some benchmarking quite a while back, but don't remember the details. Note though that marshals are easier to break in odd ways -- they're basically a tool too support .pycs so were never terribly robust. Pickles generally better for object trees too, especially if you might have cycles. OTOH, binary fast pickles for simple data structures might perform equally well. -Barry From claw@kanga.nu Thu Jul 25 20:10:27 2002 From: claw@kanga.nu (J C Lawrence) Date: Thu, 25 Jul 2002 12:10:27 -0700 Subject: [Mailman-Developers] Re: Why both a .msg and .db in qfiles? In-Reply-To: Message from barry@python.org (Barry A. Warsaw) of "Thu, 25 Jul 2002 14:57:01 EDT." <15680.18941.243085.925884@anthem.wooz.org> References: <29020.1027565599@kanga.nu> <15680.10538.703065.588561@anthem.wooz.org> <15680.18941.243085.925884@anthem.wooz.org> Message-ID: <6806.1027624227@kanga.nu> On Thu, 25 Jul 2002 14:57:01 -0400 Barry A Warsaw wrote: > For something as simple as a dictionary (which the metadata is), I > believe so. I did some benchmarking quite a while back, but don't > remember the details. Note though that marshals are easier to break > in odd ways -- they're basically a tool too support .pycs so were > never terribly robust. Pickles generally better for object trees too, > especially if you might have cycles. OTOH, binary fast pickles for > simple data structures might perform equally well. Points briefly at Jelly and Banana: http://twistedmatrix.com/products/spread I've been pleased with the performance curves of both in early testing here. -- 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 barry@python.org Thu Jul 25 20:22:14 2002 From: barry@python.org (Barry A. Warsaw) Date: Thu, 25 Jul 2002 15:22:14 -0400 Subject: [Mailman-Developers] Re: Why both a .msg and .db in qfiles? References: <29020.1027565599@kanga.nu> <15680.10538.703065.588561@anthem.wooz.org> <15680.18941.243085.925884@anthem.wooz.org> <6806.1027624227@kanga.nu> Message-ID: <15680.20454.932722.654975@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: >> For something as simple as a dictionary (which the metadata >> is), I believe so. I did some benchmarking quite a while back, >> but don't remember the details. Note though that marshals are >> easier to break in odd ways -- they're basically a tool too >> support .pycs so were never terribly robust. Pickles generally >> better for object trees too, especially if you might have >> cycles. OTOH, binary fast pickles for simple data structures >> might perform equally well. JCL> Points briefly at Jelly and Banana: JCL> http://twistedmatrix.com/products/spread JCL> I've been pleased with the performance curves of both in JCL> early testing here. Interesting stuff. I've known about Twisted for a while but hadn't realized they had those serialization protocols. I can see how that'd be useful for some distributed computing applications, especially when you're accepting hostile data. In Mailman's case, I think pickles and marshals are probably fine. They have the advantage that they're built-in tools, and we don't have to worry about hostile data (in this context). But thanks for the reference. I've had conversations with the Twisted guys at previous IPCs about Mailman and SMTP plugins. -Barry From claw@kanga.nu Thu Jul 25 20:49:32 2002 From: claw@kanga.nu (J C Lawrence) Date: Thu, 25 Jul 2002 12:49:32 -0700 Subject: [Mailman-Developers] Re: Why both a .msg and .db in qfiles? In-Reply-To: Message from barry@python.org (Barry A. Warsaw) of "Thu, 25 Jul 2002 15:22:14 EDT." <15680.20454.932722.654975@anthem.wooz.org> References: <29020.1027565599@kanga.nu> <15680.10538.703065.588561@anthem.wooz.org> <15680.18941.243085.925884@anthem.wooz.org> <6806.1027624227@kanga.nu> <15680.20454.932722.654975@anthem.wooz.org> Message-ID: <7140.1027626572@kanga.nu> On Thu, 25 Jul 2002 15:22:14 -0400 Barry A Warsaw wrote: > Interesting stuff. I've known about Twisted for a while but hadn't > realized they had those serialization protocols. I can see how that'd > be useful for some distributed computing applications, especially when > you're accepting hostile data. I have a little attention on down the road when we start exposing and distributing the process queue model more. The opportunities for hostile data insertion start growing as the system becomes more loosely coupled. > But thanks for the reference. I've had conversations with the Twisted > guys at previous IPCs about Mailman and SMTP plugins. Welcome. -- 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 barry@python.org Thu Jul 25 20:59:49 2002 From: barry@python.org (Barry A. Warsaw) Date: Thu, 25 Jul 2002 15:59:49 -0400 Subject: [Mailman-Developers] Re: Why both a .msg and .db in qfiles? References: <29020.1027565599@kanga.nu> <15680.10538.703065.588561@anthem.wooz.org> <15680.18941.243085.925884@anthem.wooz.org> <6806.1027624227@kanga.nu> <15680.20454.932722.654975@anthem.wooz.org> <7140.1027626572@kanga.nu> Message-ID: <15680.22709.43632.755371@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: >> Interesting stuff. I've known about Twisted for a while but >> hadn't realized they had those serialization protocols. I can >> see how that'd be useful for some distributed computing >> applications, especially when you're accepting hostile data. JCL> I have a little attention on down the road when we start JCL> exposing and distributing the process queue model more. The JCL> opportunities for hostile data insertion start growing as the JCL> system becomes more loosely coupled. Cool. -Barry From noreply@sourceforge.net Fri Jul 26 02:19:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jul 2002 18:19:34 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-585229 ] opening holes by changing permissions? Message-ID: Bugs item #585229, was opened at 2002-07-22 23:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585229&group_id=103 Category: configuring/installing Group: 2.1 beta >Status: Closed Resolution: None Priority: 5 Submitted By: Paul Marshall (paulmarshll) Assigned to: Nobody/Anonymous (nobody) Summary: opening holes by changing permissions? Initial Comment: I was having problems adding a list in Mailman 2.1beta via the web interface, it was giving me an error regarding permissions to the mailman/data/aliases.db file. This is the error I got: ... File "/var/mailman/Mailman/MTA/Postfix.py", line 46, in _update_maps raise RuntimeError, msg % (acmd, status, errstr) RuntimeError: command failed: /usr/sbin/postalias /var/mailman/data/aliases (status: 1, Operation not permitted) To fix this I changed the permissions on this file so apache could write to it. chmod a+w aliases.db This did fix the problem of creating and deleting lists via the web interface. Does anyone know if this would open up any security holes? Is there another way to fix the permissions problem that is more logical? Thanks for your help. Paul Marshall ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-25 21:19 Message: Logged In: YES user_id=12800 Cool, thanks, I'm closing this bug report. ---------------------------------------------------------------------- Comment By: Paul Marshall (paulmarshll) Date: 2002-07-24 11:44 Message: Logged In: YES user_id=582441 Thanks for the help bwarsaw, its working now and I don't have a+w on aliases.db Paul ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 11:28 Message: Logged In: YES user_id=12800 You shouldn't need to do this if you've followed the directions in README.POSTFIX. The key issue is that aliases and aliases.db must be group owned by `mailman' and must be group writeable. Since the cgi scripts are setgid mailman Apache should have no problems writing the file. And since Postfix filter prog is also setgid mailman, it should have no problems either. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585229&group_id=103 From noreply@sourceforge.net Fri Jul 26 04:25:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jul 2002 20:25:18 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-577919 ] Forwarding to comma separated addresses Message-ID: Bugs item #577919, was opened at 2002-07-05 16:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=577919&group_id=103 Category: Web/CGI Group: 2.0.x >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Pavel Roskin (proski) Assigned to: Nobody/Anonymous (nobody) Summary: Forwarding to comma separated addresses Initial Comment: Mailman 2.0.8 gives an option to forward mail held for approval. Entering comma separated addresses as the forwarding address doesn't cause any warnings, but the message is only delivered to the first address. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-25 23:25 Message: Logged In: YES user_id=12800 While this won't be fixed for MM2.0, I just made sure this works for MM2.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=577919&group_id=103 From noreply@sourceforge.net Fri Jul 26 04:28:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jul 2002 20:28:43 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-577617 ] Edit before approve Message-ID: Bugs item #577617, was opened at 2002-07-04 19:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=577617&group_id=103 Category: Web/CGI Group: 2.0.x >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Jasper van Beusekom (jvbeusek) Assigned to: Nobody/Anonymous (nobody) Summary: Edit before approve Initial Comment: All my list owners have made the mistake of expecting to be able to edit a message in the admindb interface before approving, assuming that the edited message would reach the list... I realize that the form-fields are truncated from the original message, but would there be some way for the owner to edit a message before approving it? ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-25 23:28 Message: Logged In: YES user_id=12800 Unfortunately at this time I've decided not to support direct editing of the message via the web page, even for MM2.1. However in 2.1, the field will be read-only so as not to confuse list administrators. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=577617&group_id=103 From noreply@sourceforge.net Fri Jul 26 04:33:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jul 2002 20:33:12 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-585833 ] Forward posts held for approval Message-ID: Bugs item #585833, was opened at 2002-07-24 06:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585833&group_id=103 Category: mail delivery Group: 2.1 beta >Status: Open Resolution: Fixed Priority: 5 Submitted By: Ousmane Wilane (wilane) Assigned to: Nobody/Anonymous (nobody) Summary: Forward posts held for approval Initial Comment: FWIW I'm using the current cvs. When I forward a mail which was held for approval to my email address (oversized mail in this case) I get the provided traceback in my logs and the mail in shunt q: ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-25 23:33 Message: Logged In: YES user_id=12800 I'm re-opening this bug report. Can you upload the .pck and .db files for the message that won't unshunt? ---------------------------------------------------------------------- Comment By: Ousmane Wilane (wilane) Date: 2002-07-24 13:26 Message: Logged In: YES user_id=47556 I swear I did restart it :):) More seriously I stop postfix, apache, mailman before upgrading as outlined in the UPGRADING file ... :) I also did verify that ListAdmin.py 2.39 was checked out This time I'll paste the traceback here (it's thrown in logs/error when I try to unshunt the messages): Jul 24 17:17:25 2002 (30049) Traceback (most recent call last): File "/usr/local/mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/usr/local/mailman/Mailman/Queue/Runner.py", line 154, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Queue/OutgoingRunner.py", line 61, in _dispose self._func(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Handlers/SMTPDirect.py", line 134, in process deliveryfunc(mlist, msg, msgdata, envsender, refused, conn) File "/usr/local/mailman/Mailman/Handlers/SMTPDirect.py", line 307, in bulkdeliver msgtext = msg.as_string() File "/usr/local/mailman/pythonlib/email/Message.py", line 99, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/local/mailman/pythonlib/email/Generator.py", line 81, in flatten self._write(msg) File "/usr/local/mailman/pythonlib/email/Generator.py", line 109, in _write self._dispatch(msg) File "/usr/local/mailman/pythonlib/email/Generator.py", line 141, in _dispatch meth(msg) File "/usr/local/mailman/pythonlib/email/Generator.py", line 283, in _handle_message g.flatten(msg.get_payload(0), unixfrom=0) File "/usr/local/mailman/pythonlib/email/Message.py", line 167, in get_payload raise TypeError, i TypeError: 0 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 11:46 Message: Logged In: YES user_id=12800 Be sure you "mailmanctl restart" :) ---------------------------------------------------------------------- Comment By: Ousmane Wilane (wilane) Date: 2002-07-24 11:26 Message: Logged In: YES user_id=47556 Oops! After cvs -q up -P -d, The bug stood there with the same traceback. Maybe I'm doing something wrong but don't know what ... :) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 10:04 Message: Logged In: YES user_id=12800 Fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585833&group_id=103 From barry@zope.com Fri Jul 26 04:38:16 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 25 Jul 2002 23:38:16 -0400 Subject: [Mailman-Developers] Modifying mailman to filter archived messages References: <200207151634.51587.laurence@digitalpulp.com> <200207241214.04173.laurence@digitalpulp.com> <15678.55345.31486.582961@anthem.wooz.org> <200207241303.15969.laurence@digitalpulp.com> Message-ID: <15680.50216.802879.848131@anthem.wooz.org> >>>>> "LB" == Laurence Berland writes: LB> Ouch-I guess I missed this little detail. I'm trying to get an LB> idea of how best to do this. Does this work? (easier in pcode LB> than english): If all you care about is modifying text/plain parts, this should be much simpler: from email.Iterators import typed_subpart_iterator ... def munge(msg): for part in typed_subpart_iterator(msg, 'text', 'plain'): body = part.get_payload() newbody = hack_body(body) part.set_payload(newbody) Cheers, -Barry From barry@zope.com Fri Jul 26 04:41:09 2002 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 25 Jul 2002 23:41:09 -0400 Subject: [Mailman-Developers] Mm documentation server change References: <5.1.0.14.2.20020724112046.035f0338@staffmail.imsa.edu> Message-ID: <15680.50389.801863.329973@anthem.wooz.org> >>>>> "CK" == Christopher Kolar writes: CK> IMSA will be making some significant server changes this CK> weekend, changes that will impact the location of the Mailman CK> documents that we host. The new URL will be: CK> http://staff.imsa.edu/~ckolar/mailman CK> The pages will no longer be hosted on www.imsa.edu. There CK> will be NO URL FORWARDING when the change is made this CK> Saturday morning, so please change links as necessary. Thanks for the update Chris. I've fixed the web page and will push it out when I push out the new beta. Should I update the hyperlink to your name to be http://staff.imsa.edu/~ckolar as well? -Barry From noreply@sourceforge.net Fri Jul 26 04:49:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jul 2002 20:49:02 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-574240 ] web ui confirm button placement Message-ID: Bugs item #574240, was opened at 2002-06-26 15:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=574240&group_id=103 Category: (un)subscribing Group: 2.1 beta >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Christopher Kolar (ckolar) Assigned to: Nobody/Anonymous (nobody) Summary: web ui confirm button placement Initial Comment: Hi. Running 2.1b2 I just did a test subscription via email. When I clicked on the link to confirm the confirmation page came up properly. I am a bit bugged by the UI though. The Confirm button was way off to the left -- right under all of the user informaiton on the screen was the "dismiss and discard" button (or whatever it was labeled). After checking the info on the screen I very nearly hit the button because I could not see the real confirm burron and the discard button, being placed right under the info, seemed to instinctively be a good place for a confirm button. I would change the UI to at least get both of them in the center. Cheers, --chris ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-25 23:49 Message: Logged In: YES user_id=12800 Done. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=574240&group_id=103 From noreply@sourceforge.net Fri Jul 26 04:51:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 25 Jul 2002 20:51:20 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-572822 ] real_name attribute not changed Message-ID: Bugs item #572822, was opened at 2002-06-23 14:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=572822&group_id=103 Category: configuring/installing Group: 2.0.x >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Christine Charity (ccharity) Assigned to: Nobody/Anonymous (nobody) Summary: real_name attribute not changed Initial Comment: When trying to change the name of a mailing list from MAILINGLISTNAME to mailinglistname (lowercase) the following error is returned: real_name attribute not changed! It must differ from the list's name by case only. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-25 23:51 Message: Logged In: YES user_id=12800 Works okay for me in MM 2.0.12 and 2.1cvs. Are you sure you didn't accidently add a space to the end of the new name? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=572822&group_id=103 From noreply@sourceforge.net Fri Jul 26 14:52:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jul 2002 06:52:49 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-585833 ] Forward posts held for approval Message-ID: Bugs item #585833, was opened at 2002-07-24 06:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585833&group_id=103 Category: mail delivery Group: 2.1 beta Status: Open Resolution: Fixed Priority: 5 Submitted By: Ousmane Wilane (wilane) Assigned to: Nobody/Anonymous (nobody) Summary: Forward posts held for approval Initial Comment: FWIW I'm using the current cvs. When I forward a mail which was held for approval to my email address (oversized mail in this case) I get the provided traceback in my logs and the mail in shunt q: ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-26 09:52 Message: Logged In: YES user_id=12800 It was a bogus pickle, probably created during the transition of the email package. The fix is simple: x = msg.get_payload() msg.set_payload([x]) I've attached a fixed message pickle below, substitute that for your .pck and see if that works for you. ---------------------------------------------------------------------- Comment By: Ousmane Wilane (wilane) Date: 2002-07-26 08:15 Message: Logged In: YES user_id=47556 The .pck and .db are attached. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-25 23:33 Message: Logged In: YES user_id=12800 I'm re-opening this bug report. Can you upload the .pck and .db files for the message that won't unshunt? ---------------------------------------------------------------------- Comment By: Ousmane Wilane (wilane) Date: 2002-07-24 13:26 Message: Logged In: YES user_id=47556 I swear I did restart it :):) More seriously I stop postfix, apache, mailman before upgrading as outlined in the UPGRADING file ... :) I also did verify that ListAdmin.py 2.39 was checked out This time I'll paste the traceback here (it's thrown in logs/error when I try to unshunt the messages): Jul 24 17:17:25 2002 (30049) Traceback (most recent call last): File "/usr/local/mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/usr/local/mailman/Mailman/Queue/Runner.py", line 154, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Queue/OutgoingRunner.py", line 61, in _dispose self._func(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Handlers/SMTPDirect.py", line 134, in process deliveryfunc(mlist, msg, msgdata, envsender, refused, conn) File "/usr/local/mailman/Mailman/Handlers/SMTPDirect.py", line 307, in bulkdeliver msgtext = msg.as_string() File "/usr/local/mailman/pythonlib/email/Message.py", line 99, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/local/mailman/pythonlib/email/Generator.py", line 81, in flatten self._write(msg) File "/usr/local/mailman/pythonlib/email/Generator.py", line 109, in _write self._dispatch(msg) File "/usr/local/mailman/pythonlib/email/Generator.py", line 141, in _dispatch meth(msg) File "/usr/local/mailman/pythonlib/email/Generator.py", line 283, in _handle_message g.flatten(msg.get_payload(0), unixfrom=0) File "/usr/local/mailman/pythonlib/email/Message.py", line 167, in get_payload raise TypeError, i TypeError: 0 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 11:46 Message: Logged In: YES user_id=12800 Be sure you "mailmanctl restart" :) ---------------------------------------------------------------------- Comment By: Ousmane Wilane (wilane) Date: 2002-07-24 11:26 Message: Logged In: YES user_id=47556 Oops! After cvs -q up -P -d, The bug stood there with the same traceback. Maybe I'm doing something wrong but don't know what ... :) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 10:04 Message: Logged In: YES user_id=12800 Fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585833&group_id=103 From noreply@sourceforge.net Fri Jul 26 13:15:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 26 Jul 2002 05:15:30 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-585833 ] Forward posts held for approval Message-ID: Bugs item #585833, was opened at 2002-07-24 10:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585833&group_id=103 Category: mail delivery Group: 2.1 beta Status: Open Resolution: Fixed Priority: 5 Submitted By: Ousmane Wilane (wilane) Assigned to: Nobody/Anonymous (nobody) Summary: Forward posts held for approval Initial Comment: FWIW I'm using the current cvs. When I forward a mail which was held for approval to my email address (oversized mail in this case) I get the provided traceback in my logs and the mail in shunt q: ---------------------------------------------------------------------- >Comment By: Ousmane Wilane (wilane) Date: 2002-07-26 12:15 Message: Logged In: YES user_id=47556 The .pck and .db are attached. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-26 03:33 Message: Logged In: YES user_id=12800 I'm re-opening this bug report. Can you upload the .pck and .db files for the message that won't unshunt? ---------------------------------------------------------------------- Comment By: Ousmane Wilane (wilane) Date: 2002-07-24 17:26 Message: Logged In: YES user_id=47556 I swear I did restart it :):) More seriously I stop postfix, apache, mailman before upgrading as outlined in the UPGRADING file ... :) I also did verify that ListAdmin.py 2.39 was checked out This time I'll paste the traceback here (it's thrown in logs/error when I try to unshunt the messages): Jul 24 17:17:25 2002 (30049) Traceback (most recent call last): File "/usr/local/mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/usr/local/mailman/Mailman/Queue/Runner.py", line 154, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Queue/OutgoingRunner.py", line 61, in _dispose self._func(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Handlers/SMTPDirect.py", line 134, in process deliveryfunc(mlist, msg, msgdata, envsender, refused, conn) File "/usr/local/mailman/Mailman/Handlers/SMTPDirect.py", line 307, in bulkdeliver msgtext = msg.as_string() File "/usr/local/mailman/pythonlib/email/Message.py", line 99, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/local/mailman/pythonlib/email/Generator.py", line 81, in flatten self._write(msg) File "/usr/local/mailman/pythonlib/email/Generator.py", line 109, in _write self._dispatch(msg) File "/usr/local/mailman/pythonlib/email/Generator.py", line 141, in _dispatch meth(msg) File "/usr/local/mailman/pythonlib/email/Generator.py", line 283, in _handle_message g.flatten(msg.get_payload(0), unixfrom=0) File "/usr/local/mailman/pythonlib/email/Message.py", line 167, in get_payload raise TypeError, i TypeError: 0 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 15:46 Message: Logged In: YES user_id=12800 Be sure you "mailmanctl restart" :) ---------------------------------------------------------------------- Comment By: Ousmane Wilane (wilane) Date: 2002-07-24 15:26 Message: Logged In: YES user_id=47556 Oops! After cvs -q up -P -d, The bug stood there with the same traceback. Maybe I'm doing something wrong but don't know what ... :) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 14:04 Message: Logged In: YES user_id=12800 Fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585833&group_id=103 From mmlist@confused.org Fri Jul 26 22:39:15 2002 From: mmlist@confused.org (Will Galloway) Date: Fri, 26 Jul 2002 14:39:15 -0700 Subject: [Mailman-Developers] Daily digests and other issues Message-ID: <3.0.5.32.20020726143915.0095dcc0@209.68.8.129> Hi: I didn't see anything like this in MM-Users, so I hope it's OK to post here. I admin a ~1000 member outdoor activities list hosted at pair.com ("pairlist"), so I don't get to see the gory stuff, just the web interface. The size threshold trigger for daily digests stopped working last year, and I understand unoffically that it was a server loading issue that caused this. The server in question handles several hundred lists. Since our list has quite a bit of time sensitive info, and variable traffic levels, this feature is very important. Is there any change in the handling of this feature in 2.1.x that would reduce the CPU requirements? Or anything that pair can try to clean up their implementation to fix it? Other stuff: Duplicate and frivolous subscriptions are annoying, and a "discard" option for sub. requests would be much appreciated. Awareness of a pre-existing sub. request from the same address should be implemented. Rejection just confuses legitimate (albeit impatient) subscribers, and encourages people who are messing around to keep trying. In the same vein, the ability to modify/eliminate the default rejection message for posts would avoid antagonizing people who need coaching now and then. If true moderation and customization of all the various messages is forthcoming, then that's ideal. Thanks, Will Galloway From claw@kanga.nu Sat Jul 27 03:08:42 2002 From: claw@kanga.nu (J C Lawrence) Date: Fri, 26 Jul 2002 19:08:42 -0700 Subject: [Mailman-Developers] Cute TMDA use Message-ID: <21784.1027735722@kanga.nu> You can front a list with TMDA, pointing TMDA at your list's subscriber base and a local whitelist. TMDA then passes all subscriber mails straight thru to the list, but mail from non-subscribers is held until confirmed (at which point you can whitelist or not). The TMDA lists do this to decent effect. Nice side effects: No more problems with posters from non-subscribed addresses. They have a subscription to _GET_ mail and to define an allowed posting address. They can (trivially) define additional allowed posting addresses by just posting from them and confirming the post to get on the whitelist. You're now essentially back in the old days of the 1980s when we could safely run open lists. Almost all SPAM disappears. They don't confirm. Ditto viruses. Well some viruses might learn confirming down the road, but none do now and the confirmation steps can be trivially changed. -- 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 claw@kanga.nu Sat Jul 27 03:10:18 2002 From: claw@kanga.nu (J C Lawrence) Date: Fri, 26 Jul 2002 19:10:18 -0700 Subject: [Mailman-Developers] Re: Cute TMDA use In-Reply-To: Message from Chuq Von Rospach of "Fri, 26 Jul 2002 14:36:12 PDT." References: Message-ID: <21818.1027735818@kanga.nu> Bounced as below. On Fri, 26 Jul 2002 14:36:12 -0700 Chuq Von Rospach wrote: > Have you sent this to barry? Not yet. Mind if I just bounce the whole message I'm replying to there (and possibly this reply)? > This is GREAT! Thought you might like it. > You know, I was kinda noodling in that direction, but I hadn't figured > THIS out. Whoof. Quite nice isn't it. It effectively abstracts the concepts of getting mail from being able to send mail. You subscribe to be able to get mail from the list (which also inserts same address on the whitelist). The whitelist (which you grow by confirmations) is then the list of addresses which are allowed to post (or reach the moderation interface. Quite distinct. Very 1980s. The TMDA lists are run this way, so I can't claim its original to me. -- 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@plaidworks.com Sat Jul 27 04:06:33 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Fri, 26 Jul 2002 20:06:33 -0700 Subject: [Mailman-Developers] Re: Cute TMDA use In-Reply-To: <21818.1027735818@kanga.nu> Message-ID: On 7/26/02 7:10 PM, "J C Lawrence" wrote: >> You know, I was kinda noodling in that direction, but I hadn't figured >> THIS out. Whoof. > > Quite nice isn't it. It effectively abstracts the concepts of getting > mail from being able to send mail. Yes, it also change the paradigm of the subscription to meet the multi-protocol reality we have today. I've got two reasons why this made me sit up and take notice. First, most of us are running lists with increasingly complex distribution systems. JC has built some nice (and complex) ways to allow reading and posting off the web. We have search engines returning messages, we have people who own 35 email addresses and can't for the life of them remember passwords to 6, much less which is subscribed to what. Some of us gateway into NNTP, and not all users think to follow up. They reply instead, so it hits the admin queue. And the admin has to figure out what's postable and what isn't. Many of us admins "solve" this by simply saying "if you ain't on the list, you ain't getting in". Which leads to.... Second, Barry, remember when you had to turn mailman-users into subscriber only? How you hated doing it, but the spammers made it necessary? (as the guy who runs the queue of mailman-users every couple of days, it hasn't gotten any better. Ugh). But that builds delays into those postings, which isn't good. But as the spammers have gotten more aggressive and better at sneaking past the gates, we've had to build bigger gates with nastier barbed wire. I've grown more and more worried that mailing lists were turning into armed camps, or gated communities. Or little paranoid balls of bodies unwilling to look out the peephole when someone rings the bell. Is that really what we wanted when we got involved with running lists? I've been increasingly uncomfortable with the "gaza strip" aspect of running lists. This seems to me a great way to open those gates a bit -- safely. And build in some understanding that not everyone who's "subscribed" is in the subscriber lists. You have the archives, and the gateways, and the extended populations that are effectively disenfranchised from posting today. This builds a system that re-enfranchises them with minimal hassle and minimal risk of opening the door to the bad guys. I think it's a great hack to get back to what we WANT lists to act like, not what we've been slowly forced to turn them into. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ IMHO: Jargon. Acronym for In My Humble Opinion. Used to flag as an opinion something that is clearly from context an opinion to everyone except the mentally dense. Opinions flagged by IMHO are actually rarely humble. IMHO. (source: third unabridged dictionary of chuqui-isms). From claw@kanga.nu Sat Jul 27 04:55:31 2002 From: claw@kanga.nu (J C Lawrence) Date: Fri, 26 Jul 2002 20:55:31 -0700 Subject: [Mailman-Developers] Re: Cute TMDA use In-Reply-To: Message from Chuq Von Rospach of "Fri, 26 Jul 2002 20:06:33 PDT." References: Message-ID: <22523.1027742131@kanga.nu> On Fri, 26 Jul 2002 20:06:33 -0700 Chuq Von Rospach wrote: > On 7/26/02 7:10 PM, "J C Lawrence" wrote: >>> You know, I was kinda noodling in that direction, but I hadn't >>> figured THIS out. Whoof. >> Quite nice isn't it. It effectively abstracts the concepts of >> getting mail from being able to send mail. > Yes, it also change the paradigm of the subscription to meet the > multi-protocol reality we have today. Precisely. I figured you'd grab that bit and disappear over the horizon. > First, most of us are running lists with increasingly complex > distribution systems. JC has built some nice (and complex) ways to > allow reading and posting off the web. Thanks. Its a bit messy on the server side, but trivial from the user/web side. You get a "Reply" link and then a form with a TEXTAREA containing a properly quoted and attributed message you can type into. It even does The Right Thing with In-Reply-To: and References: headers. > I've been increasingly uncomfortable with the "gaza strip" aspect of > running lists. This seems to me a great way to open those gates a bit > -- safely. And build in some understanding that not everyone who's > "subscribed" is in the subscriber lists. You have the archives, and > the gateways, and the extended populations that are effectively > disenfranchised from posting today. This builds a system that > re-enfranchises them with minimal hassle and minimal risk of opening > the door to the bad guys. Aye, its a big step forward for our side in the cold war. > I think it's a great hack to get back to what we WANT lists to act > like, not what we've been slowly forced to turn them into. I've moved my previous mimefilter stuff under procmail, and have thrown TMDA into the loop with it as well (damned trivial actually, tho a bit messy on file-permissions). After a week or so of testing and play I'll post the recipe here and in the FAQ. Idle thought: Some lists have currency requirements. They discuss current events and really only want messages which are, well, current. A possible TMDA address: 1) Configure your MTA to run all outbound mail deliveries thru a filter which calls `tmda-inject` prior to delivery. For details of how I did this under Exim see: http://mla.libertine.org/tmda-users/200207/msg00308.html http://mla.libertine.org/tmda-users/200207/msg00309.html Doing similar under Postfix should be easy but I've not looked into it. 2) Write an outbound filter for TMDA which rewrites all list posts with a Reply-To: to a dated version of the list address. 3) Write a TMDA inbound filter to bounce/discard all list mail sent to a stale dated address. Result: All replies to the list which are "too old" are bounced/dropped. Currency! -- 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 claw@kanga.nu Sat Jul 27 05:02:47 2002 From: claw@kanga.nu (J C Lawrence) Date: Fri, 26 Jul 2002 21:02:47 -0700 Subject: [Mailman-Developers] Re: Cute TMDA use In-Reply-To: Message from J C Lawrence of "Fri, 26 Jul 2002 20:55:31 PDT." <22523.1027742131@kanga.nu> References: <22523.1027742131@kanga.nu> Message-ID: <22614.1027742567@kanga.nu> On Fri, 26 Jul 2002 20:55:31 -0700 J C Lawrence wrote: > Idle thought: While I don't have time to do this right now, is there any interest here in making a developing and testing list configuration under TMDA which re-writes all poster addresses to dated addresses at the list server, and then forwards mail to those addresses back to the original address? There are messy bits in the details of getting that to work, but it could be interesting, not only for harvesting control but for lists where poster anonymity AND the ability to privately email posters are both desired. -- 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 noreply@sourceforge.net Sat Jul 27 15:29:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 27 Jul 2002 07:29:52 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-585833 ] Forward posts held for approval Message-ID: Bugs item #585833, was opened at 2002-07-24 10:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585833&group_id=103 Category: mail delivery Group: 2.1 beta Status: Open Resolution: Fixed Priority: 5 Submitted By: Ousmane Wilane (wilane) Assigned to: Nobody/Anonymous (nobody) Summary: Forward posts held for approval Initial Comment: FWIW I'm using the current cvs. When I forward a mail which was held for approval to my email address (oversized mail in this case) I get the provided traceback in my logs and the mail in shunt q: ---------------------------------------------------------------------- >Comment By: Ousmane Wilane (wilane) Date: 2002-07-27 14:29 Message: Logged In: YES user_id=47556 My shunt dir is clean. Thanks a lot. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-26 13:52 Message: Logged In: YES user_id=12800 It was a bogus pickle, probably created during the transition of the email package. The fix is simple: x = msg.get_payload() msg.set_payload([x]) I've attached a fixed message pickle below, substitute that for your .pck and see if that works for you. ---------------------------------------------------------------------- Comment By: Ousmane Wilane (wilane) Date: 2002-07-26 12:15 Message: Logged In: YES user_id=47556 The .pck and .db are attached. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-26 03:33 Message: Logged In: YES user_id=12800 I'm re-opening this bug report. Can you upload the .pck and .db files for the message that won't unshunt? ---------------------------------------------------------------------- Comment By: Ousmane Wilane (wilane) Date: 2002-07-24 17:26 Message: Logged In: YES user_id=47556 I swear I did restart it :):) More seriously I stop postfix, apache, mailman before upgrading as outlined in the UPGRADING file ... :) I also did verify that ListAdmin.py 2.39 was checked out This time I'll paste the traceback here (it's thrown in logs/error when I try to unshunt the messages): Jul 24 17:17:25 2002 (30049) Traceback (most recent call last): File "/usr/local/mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/usr/local/mailman/Mailman/Queue/Runner.py", line 154, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Queue/OutgoingRunner.py", line 61, in _dispose self._func(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Handlers/SMTPDirect.py", line 134, in process deliveryfunc(mlist, msg, msgdata, envsender, refused, conn) File "/usr/local/mailman/Mailman/Handlers/SMTPDirect.py", line 307, in bulkdeliver msgtext = msg.as_string() File "/usr/local/mailman/pythonlib/email/Message.py", line 99, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/local/mailman/pythonlib/email/Generator.py", line 81, in flatten self._write(msg) File "/usr/local/mailman/pythonlib/email/Generator.py", line 109, in _write self._dispatch(msg) File "/usr/local/mailman/pythonlib/email/Generator.py", line 141, in _dispatch meth(msg) File "/usr/local/mailman/pythonlib/email/Generator.py", line 283, in _handle_message g.flatten(msg.get_payload(0), unixfrom=0) File "/usr/local/mailman/pythonlib/email/Message.py", line 167, in get_payload raise TypeError, i TypeError: 0 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 15:46 Message: Logged In: YES user_id=12800 Be sure you "mailmanctl restart" :) ---------------------------------------------------------------------- Comment By: Ousmane Wilane (wilane) Date: 2002-07-24 15:26 Message: Logged In: YES user_id=47556 Oops! After cvs -q up -P -d, The bug stood there with the same traceback. Maybe I'm doing something wrong but don't know what ... :) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 14:04 Message: Logged In: YES user_id=12800 Fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585833&group_id=103 From noreply@sourceforge.net Sat Jul 27 17:23:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sat, 27 Jul 2002 09:23:37 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-585833 ] Forward posts held for approval Message-ID: Bugs item #585833, was opened at 2002-07-24 06:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585833&group_id=103 Category: mail delivery Group: 2.1 beta >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Ousmane Wilane (wilane) Assigned to: Nobody/Anonymous (nobody) Summary: Forward posts held for approval Initial Comment: FWIW I'm using the current cvs. When I forward a mail which was held for approval to my email address (oversized mail in this case) I get the provided traceback in my logs and the mail in shunt q: ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-27 12:23 Message: Logged In: YES user_id=12800 Cool ---------------------------------------------------------------------- Comment By: Ousmane Wilane (wilane) Date: 2002-07-27 10:29 Message: Logged In: YES user_id=47556 My shunt dir is clean. Thanks a lot. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-26 09:52 Message: Logged In: YES user_id=12800 It was a bogus pickle, probably created during the transition of the email package. The fix is simple: x = msg.get_payload() msg.set_payload([x]) I've attached a fixed message pickle below, substitute that for your .pck and see if that works for you. ---------------------------------------------------------------------- Comment By: Ousmane Wilane (wilane) Date: 2002-07-26 08:15 Message: Logged In: YES user_id=47556 The .pck and .db are attached. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-25 23:33 Message: Logged In: YES user_id=12800 I'm re-opening this bug report. Can you upload the .pck and .db files for the message that won't unshunt? ---------------------------------------------------------------------- Comment By: Ousmane Wilane (wilane) Date: 2002-07-24 13:26 Message: Logged In: YES user_id=47556 I swear I did restart it :):) More seriously I stop postfix, apache, mailman before upgrading as outlined in the UPGRADING file ... :) I also did verify that ListAdmin.py 2.39 was checked out This time I'll paste the traceback here (it's thrown in logs/error when I try to unshunt the messages): Jul 24 17:17:25 2002 (30049) Traceback (most recent call last): File "/usr/local/mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/usr/local/mailman/Mailman/Queue/Runner.py", line 154, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Queue/OutgoingRunner.py", line 61, in _dispose self._func(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Handlers/SMTPDirect.py", line 134, in process deliveryfunc(mlist, msg, msgdata, envsender, refused, conn) File "/usr/local/mailman/Mailman/Handlers/SMTPDirect.py", line 307, in bulkdeliver msgtext = msg.as_string() File "/usr/local/mailman/pythonlib/email/Message.py", line 99, in as_string g.flatten(self, unixfrom=unixfrom) File "/usr/local/mailman/pythonlib/email/Generator.py", line 81, in flatten self._write(msg) File "/usr/local/mailman/pythonlib/email/Generator.py", line 109, in _write self._dispatch(msg) File "/usr/local/mailman/pythonlib/email/Generator.py", line 141, in _dispatch meth(msg) File "/usr/local/mailman/pythonlib/email/Generator.py", line 283, in _handle_message g.flatten(msg.get_payload(0), unixfrom=0) File "/usr/local/mailman/pythonlib/email/Message.py", line 167, in get_payload raise TypeError, i TypeError: 0 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 11:46 Message: Logged In: YES user_id=12800 Be sure you "mailmanctl restart" :) ---------------------------------------------------------------------- Comment By: Ousmane Wilane (wilane) Date: 2002-07-24 11:26 Message: Logged In: YES user_id=47556 Oops! After cvs -q up -P -d, The bug stood there with the same traceback. Maybe I'm doing something wrong but don't know what ... :) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 10:04 Message: Logged In: YES user_id=12800 Fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585833&group_id=103 From JasonR.Mastaler Mon Jul 29 03:14:42 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Sun, 28 Jul 2002 20:14:42 -0600 Subject: [Mailman-Developers] Re: Cute TMDA use References: <22523.1027742131@kanga.nu> <22614.1027742567@kanga.nu> Message-ID: J C Lawrence writes: > While I don't have time to do this right now, is there any interest > here in making a developing and testing list configuration under > TMDA which re-writes all poster addresses to dated addresses at the > list server, and then forwards mail to those addresses back to the > original address? There are messy bits in the details of getting > that to work, but it could be interesting, not only for harvesting > control but for lists where poster anonymity AND the ability to > privately email posters are both desired. For a very similar approach, see what Gmane is doing: http://gmane.org/tmda.php -- (http://tmda.net/) From JasonR.Mastaler Mon Jul 29 03:25:33 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Sun, 28 Jul 2002 20:25:33 -0600 Subject: [Mailman-Developers] Re: Cute TMDA use References: <21784.1027735722@kanga.nu> Message-ID: J C Lawrence writes: > No more problems with posters from non-subscribed addresses. They > have a subscription to _GET_ mail and to define an allowed posting > address. They can (trivially) define additional allowed posting > addresses by just posting from them and confirming the post to get on > the whitelist. Yup. One thing I also do is share an auto-whitelist among all the lists on my server. So, if claw@kanga.nu confirms his post to tmda-users, he'll instantly be able to post to tmda-workers as well. This makes things even more transparent for the end-user, particularly at sites hosting many lists. > You're now essentially back in the old days of the 1980s when we > could safely run open lists. Once in a blue moon, a spammer will actually confirm his spam to a list, which then requires a bit of intervention to remove the address from the auto-whitelist, and blacklist it. But, you'll also now have a verifiable address to use to track him down and fry his ass . However, this is rare. It hasn't happened on any of my lists in the five months since I implemented this setup. -- (http://tmda.net/) From JasonR.Mastaler Mon Jul 29 03:49:45 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Sun, 28 Jul 2002 20:49:45 -0600 Subject: [Mailman-Developers] Integrating TMDA (was Re: Cute TMDA use) References: <21784.1027735722@kanga.nu> Message-ID: On another note, the logical approach IMO is to build this functionality into Mailman, rather than having to attach TMDA to your Mailman installation. TMDA includes much more than is relevant for protecting a mailing list. Mailman already includes most of the tools to make this work. TMDA's challenge system is no more complex than how Mailman verifies a new subscriber. Once you turned this feature on, Mailman would store unconfirmed incoming messages under qfiles/ somewhere, prompt for confirmation, and release the message to the list once the confirmation is returned. I envision Mailman's web configuration interface making this very easy. A checkbox to toggle whether existing subscribers are allowed through, a textbox to enter explicitly blacklisted addresses, etc. Gravy like the "auto-whitelist" feature could be stolen from TMDA (also a pure-Python, GPL'd app) if necessary. I'd expect this to be no more than a few days work for someone intimately familiar with Mailman's source. I don't know of any MLM with this functionality built-in, and it will virtually eliminate all spam. How's that for motivation? -- (http://tmda.net/) From chuqui@plaidworks.com Mon Jul 29 04:14:04 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Sun, 28 Jul 2002 20:14:04 -0700 Subject: [Mailman-Developers] Integrating TMDA (was Re: Cute TMDA use) In-Reply-To: Message-ID: On 7/28/02 7:49 PM, "Jason R. Mastaler" wrote: > On another note, the logical approach IMO is to build this > functionality into Mailman, Yup. And Barry's already made positive-sounding noises, but holding up release 2.1 to add this doesn't make sense. But making it a focus of 2.2 or 3.0 does. I think we need to finish 2.1, and then start the next round of enhancements. We don't want to get into "always another last featuer" mode. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ No! No! Dead girl, OFF the table! -- Shrek From JasonR.Mastaler Mon Jul 29 04:58:42 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Sun, 28 Jul 2002 21:58:42 -0600 Subject: [Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use) References: Message-ID: Chuq Von Rospach writes: > holding up release 2.1 to add this doesn't make sense. I didn't suggest that it did. > But making it a focus of 2.2 or 3.0 does. I think we need to finish > 2.1, and then start the next round of enhancements. Works for me. -- (http://tmda.net/) From claw@kanga.nu Mon Jul 29 07:01:17 2002 From: claw@kanga.nu (J C Lawrence) Date: Sun, 28 Jul 2002 23:01:17 -0700 Subject: [Mailman-Developers] Re: Cute TMDA use In-Reply-To: Message from Jason R.Mastaler of "Sun, 28 Jul 2002 20:25:33 MDT." References: <21784.1027735722@kanga.nu> Message-ID: <9480.1027922477@kanga.nu> On Sun, 28 Jul 2002 20:25:33 -0600 Jason R Mastaler wrote: > J C Lawrence writes: >> No more problems with posters from non-subscribed addresses. They >> have a subscription to _GET_ mail and to define an allowed posting >> address. They can (trivially) define additional allowed posting >> addresses by just posting from them and confirming the post to get on >> the whitelist. > Yup. One thing I also do is share an auto-whitelist among all the > lists on my server. So, if claw@kanga.nu confirms his post to > tmda-users, he'll instantly be able to post to tmda-workers as well. > This makes things even more transparent for the end-user, particularly > at sites hosting many lists. True. There are cases where I don't want this however, and its proving rather a bitch to make a non-shared whitelist hang off a shared configuration (in my case a shared procmail RC). -- 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 claw@kanga.nu Mon Jul 29 07:02:50 2002 From: claw@kanga.nu (J C Lawrence) Date: Sun, 28 Jul 2002 23:02:50 -0700 Subject: [Mailman-Developers] Integrating TMDA (was Re: Cute TMDA use) In-Reply-To: Message from Jason R.Mastaler of "Sun, 28 Jul 2002 20:49:45 MDT." References: <21784.1027735722@kanga.nu> Message-ID: <9508.1027922570@kanga.nu> On Sun, 28 Jul 2002 20:49:45 -0600 Jason R Mastaler wrote: > On another note, the logical approach IMO is to build this > functionality into Mailman, rather than having to attach TMDA to your > Mailman installation. TMDA includes much more than is relevant for > protecting a mailing list. Given that the TMDA python product carries almost all the needed payload, I wonder if a TMDA-plugin rooted in the TMDA product doesn't make more sense. -- 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 noreply@sourceforge.net Mon Jul 29 17:17:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jul 2002 09:17:23 -0700 Subject: [Mailman-Developers] [ mailman-Patches-585643 ] Mailman 2.0.13 candidate patch Message-ID: Patches item #585643, was opened at 2002-07-23 18:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=585643&group_id=103 Category: None Group: Mailman 2.0.x >Status: Closed >Resolution: Accepted Priority: 8 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Mailman 2.0.13 candidate patch Initial Comment: Mailman 2.0.12 had compatibility problems with Python 1.5.2. This patch fixes these AFAICT, and a few other small bugs that have cropped up. Note that this is a candidate patch. The actual MM2.0.13 patch may be different. However I would really appreciate folks using Mailman 2.0.12 (especially if you're using Python 1.5.2) to give this patch a try and see if it fixes your problems. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-29 12:17 Message: Logged In: YES user_id=12800 I'm releasing MM2.0.13 today. It will be slightly different than this patch. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-07-25 12:00 Message: Logged In: NO This fixed the problems I'd been having on my Solaris 8 box running Mailman 2.0.12 and Python 1.52. Thanks much. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=585643&group_id=103 From JasonR.Mastaler Mon Jul 29 17:47:02 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Mon, 29 Jul 2002 10:47:02 -0600 Subject: [Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use) References: <21784.1027735722@kanga.nu> <9508.1027922570@kanga.nu> Message-ID: J C Lawrence writes: > Given that the TMDA python product carries almost all the needed > payload, I wonder if a TMDA-plugin rooted in the TMDA product > doesn't make more sense. I'm comfortable with this as well, and don't mind making modifications to TMDA that would make this easier if that proves necessary. Since Mailman is the larger and more complex of the two, this should probably be spearheaded by someone familiar with Mailman, rather than the other way around. I'll be happy to assist on the TMDA side. -- (http://tmda.net/) From JasonR.Mastaler Mon Jul 29 17:51:46 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Mon, 29 Jul 2002 10:51:46 -0600 Subject: [Mailman-Developers] Re: Cute TMDA use References: <21784.1027735722@kanga.nu> <9480.1027922477@kanga.nu> Message-ID: J C Lawrence writes: > There are cases where I don't want this however, and its proving > rather a bitch to make a non-shared whitelist hang off a shared > configuration (in my case a shared procmail RC). I haven't found this to be the case at all, but I'm also driving my setup with dot-qmail files which makes this sort of thing trivial. -- (http://tmda.net/) From claw@kanga.nu Mon Jul 29 18:22:14 2002 From: claw@kanga.nu (J C Lawrence) Date: Mon, 29 Jul 2002 10:22:14 -0700 Subject: [Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use) In-Reply-To: Message from Jason R.Mastaler of "Mon, 29 Jul 2002 10:47:02 MDT." References: <21784.1027735722@kanga.nu> <9508.1027922570@kanga.nu> Message-ID: <13773.1027963334@kanga.nu> On Mon, 29 Jul 2002 10:47:02 -0600 Jason R Mastaler wrote: > J C Lawrence writes: >> Given that the TMDA python product carries almost all the needed >> payload, I wonder if a TMDA-plugin rooted in the TMDA product doesn't >> make more sense. > I'm comfortable with this as well, and don't mind making modifications > to TMDA that would make this easier if that proves necessary. Not speaking for Barry, but there are large advantages to leveraging code that other people maintain vs increasing the code and maintenance load of Mailman. -- 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 barry@zope.com Mon Jul 29 18:50:31 2002 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 29 Jul 2002 13:50:31 -0400 Subject: [Mailman-Developers] RELEASED Mailman 2.0.13 Message-ID: <15685.32871.578530.632994@anthem.wooz.org> I've released Mailman 2.0.13 which fixes some incompatibilties with Python 1.5.2 that crept into Mailman 2.0.12. This also fixes a minor configure incompatibility on Solaris platforms (and possibly others). If you're using Python 1.5.2 with Mailman 2.0.12 you should definitely upgrade. The upgrade is safe if you're using newer Python versions too. See the NEWS file excerpt below. As usual, I've made both full source tarballs and patches available. See http://sourceforge.net/project/showfiles.php?group_id=103 for links to download all the patches and the source tarball. If you decide to install the patches, please do read the release notes first: http://sourceforge.net/project/shownotes.php?release_id=97760 See also: http://www.gnu.org/software/mailman http://www.list.org http://mailman.sf.net Cheers, -Barry -------------------- snip snip -------------------- 2.0.13 (29-Jul-2002) - Fixed some Python 1.5.2 compatibility problems that crept into Mailman 2.0.12. - Fixed some configure script incompatibilities on certain platforms. From JasonR.Mastaler Mon Jul 29 18:56:43 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Mon, 29 Jul 2002 11:56:43 -0600 Subject: [Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use) References: <21784.1027735722@kanga.nu> <9508.1027922570@kanga.nu> <13773.1027963334@kanga.nu> Message-ID: J C Lawrence writes: > Not speaking for Barry, but there are large advantages to leveraging > code that other people maintain vs increasing the code and > maintenance load of Mailman. True. Another benefit is that folks don't have to wait until MM 2.2 to add this functionality. -- (http://tmda.net/) From claw@kanga.nu Mon Jul 29 19:01:32 2002 From: claw@kanga.nu (J C Lawrence) Date: Mon, 29 Jul 2002 11:01:32 -0700 Subject: [Mailman-Developers] Re: Cute TMDA use In-Reply-To: Message from Jason R.Mastaler of "Mon, 29 Jul 2002 10:51:46 MDT." References: <21784.1027735722@kanga.nu> <9480.1027922477@kanga.nu> Message-ID: <14041.1027965692@kanga.nu> <> On Mon, 29 Jul 2002 10:51:46 -0600 Jason R Mastaler wrote: > J C Lawrence writes: >> There are cases where I don't want this however, and its proving >> rather a bitch to make a non-shared whitelist hang off a shared >> configuration (in my case a shared procmail RC). > I haven't found this to be the case at all, but I'm also driving my > setup with dot-qmail files which makes this sort of thing trivial. I can't comment well in reaction to QMail as I don't and haven't used it. However I suspect that it doesn't solve the problem I'm referencing, as its not MTa based or specific. I have the MTA (currently Exim and Postfix) configured to deliver all Mailman-related messages sent to the system (-owner, -admin, -request, and list posts) to a singe procmail filter (obviously, shared among all lists and aliases). I'm using procmail as I'm also doing MIME filtering and other pre-processing of messages before handing them to TMDA or the MLM. To goal is arrive at a configuration where no maintenance or extra/unusual actions are required; of alias files, dot files, TMDA configs, TMDA filters, etc as lists are added and removed from the system, or for the normal running and operation of a list. On the TMDA side what I'd like to arrive at a configuration where: -- blacklists are shared -- each list has an auto-whitelist which is private to that list -- each list authenticates messages sent to it against the appropriate Mailman config.db. -- In validating a message for a given list no files or sources other than the shared blacklist, the private whitelist, and the list-specific roster are checked. Essentially this means a fully private TMDA filter setup for each list (modulo the blacklist, but I'm willing to compromise on that). Choice of TMDA incoming filter can be selected at runtime (argument to tmda-incoming) but I can't compute the contents of the incoming filter at runtime in any regard. Filter rules are single qualifier only. Filter files don't have internal variable replacement logic so that they can rewrite themselves depending on the Sender or similar (thus effectively providing multiple qualifier logic). The base result of these configuration constraints is that I have to write a custom incoming filter for each list, pointing at the appropriate private auto-whitelist, Mailman config etc, each filter identical to every other except for the internal list name references. I'd rather have a single self-adapting incoming filter. What I'd really like is to be able to conditionally nest TMDA filters ala: # Generic access controls from-file ~list/.tmda/lists/blacklist bounce from-file ~list/.tmda/lists/whitelist ok # Custom list specific filters (includes file if exists) #include-if "~list/.tmda/filters/${LISTNAME}" # Generic list-specific filters from-file ~list/.tmda/lists/whitelist.${LISTNAME}.auto ok from-mailman -attr=members ~list/lists/${LISTNAME} ok from-mailman -attr=digest_members ~list/lists/${LISTNAME} ok from ${LISTNAME}-admin@kanga.nu ok from ${LISTNAME}-owner@kanga.nu ok That way if I should want to add extra constraints, authentication sources, behaviours etc to a given list I can, just by dropping a file in the filters directory. Currently I'm hacking my way around this by having a wrapper shell script which assembles a PID-specific incoming filter in /tmp, calls tmda-filter against it, and then deletes it afterward in cleanup. Ugly, expensive, hackish, but works. -- 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 JasonR.Mastaler Mon Jul 29 19:26:01 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Mon, 29 Jul 2002 12:26:01 -0600 Subject: [Mailman-Developers] Re: Cute TMDA use References: <21784.1027735722@kanga.nu> <9480.1027922477@kanga.nu> <14041.1027965692@kanga.nu> Message-ID: J C Lawrence writes: > < interest/topicality there>> Better suited for tmda-workers, so I'm shifting it there. > Choice of TMDA incoming filter can be selected at runtime (argument > to tmda-incoming) but I can't compute the contents of the incoming > filter at runtime in any regard. Filter rules are single qualifier > only. Filter files don't have internal variable replacement logic > so that they can rewrite themselves depending on the Sender or > similar (thus effectively providing multiple qualifier logic). Ah, yes. OK, you are right, this is not something that I've solved in my setup either. Tim, how does this fit into the "macro" feature you've been working on for the FilterParser? > The base result of these configuration constraints is that I have to > write a custom incoming filter for each list, pointing at the > appropriate private auto-whitelist, Mailman config etc, each filter > identical to every other except for the internal list name > references. This is what I'm doing too. I use text parsing scripts to make mass changes, but you're right, it would be better to be able to use a single self-adapting incoming filter. > from-file ~list/.tmda/lists/whitelist.${LISTNAME}.auto ok And in your vision, where does LISTNAME come from, the environment? -- (http://tmda.net/) From noreply@sourceforge.net Mon Jul 29 20:57:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jul 2002 12:57:50 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-588222 ] Downgrade detected on 2.0.13 "upgrade"? Message-ID: Bugs item #588222, was opened at 2002-07-29 14:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=588222&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Marshall (paulmarshll) Assigned to: Nobody/Anonymous (nobody) Summary: Downgrade detected on 2.0.13 "upgrade"? Initial Comment: I am running Red Hat 7.3, Python 1.5.2, and Mailman 2.1b2. When I try to install Mailman 2.0.13 the ./configure works, however on the make install it begins working then errors out: Downgrade detected, from version 0x20100b2 to version 0x2000df0 This is probably not safe. Exiting. Now that it has done this I am unable to start Mailman up. Another person working on the system may have upgraded to Python 2.2 however, according to Barry Warsaw, newer versions of python should work just fine. Thanks for the help. Paul Marshall ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=588222&group_id=103 From noreply@sourceforge.net Mon Jul 29 21:52:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jul 2002 13:52:43 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-588222 ] Downgrade detected on 2.0.13 "upgrade"? Message-ID: Bugs item #588222, was opened at 2002-07-29 15:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=588222&group_id=103 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Paul Marshall (paulmarshll) Assigned to: Nobody/Anonymous (nobody) >Summary: Downgrade detected on 2.0.13 "upgrade"? Initial Comment: I am running Red Hat 7.3, Python 1.5.2, and Mailman 2.1b2. When I try to install Mailman 2.0.13 the ./configure works, however on the make install it begins working then errors out: Downgrade detected, from version 0x20100b2 to version 0x2000df0 This is probably not safe. Exiting. Now that it has done this I am unable to start Mailman up. Another person working on the system may have upgraded to Python 2.2 however, according to Barry Warsaw, newer versions of python should work just fine. Thanks for the help. Paul Marshall ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-29 16:52 Message: Logged In: YES user_id=12800 Um, Mailman 2.1b2 is "newer" than Mailman 2.0.13 so this is indeed a downgrade. The patch has no relevance to Mailman 2.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=588222&group_id=103 From noreply@sourceforge.net Mon Jul 29 23:29:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jul 2002 15:29:29 -0700 Subject: [Mailman-Developers] [ mailman-Patches-564747 ] Makes "powered by" icons into links Message-ID: Patches item #564747, was opened at 2002-06-05 03:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=564747&group_id=103 Category: Web UI Group: Mailman 2.0.x >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: W Isaac Carroll (zaak) Assigned to: Nobody/Anonymous (nobody) >Summary: Makes "powered by" icons into links Initial Comment: This makes the Mailman, Python, and GNU icons at the bottom of the web UI pages into links to their respective web sites. There are already links if mm_cfg.IMAGE_LOGOS is false. This patch simply makes the graphical version have the links as well. Patch against version 2.0.9 ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-29 18:29 Message: Logged In: YES user_id=12800 I'm rejecting this patch (actually without looking at the details -- sorry), because we've had too many complaints about these logos being hyperlinked. I'm actually disabling the links altogether. The problem is that the GNU, Python, and Mailman folks get way too many unrelated requests for unsubscription or other membership issues, just because frustrated people will click on anything to get their issue resolved. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=564747&group_id=103 From barry@python.org Tue Jul 30 00:31:03 2002 From: barry@python.org (Barry A. Warsaw) Date: Mon, 29 Jul 2002 19:31:03 -0400 Subject: [Mailman-Developers] Cute TMDA use References: <21784.1027735722@kanga.nu> Message-ID: <15685.53303.972678.484832@anthem.wooz.org> Very cool, thanks for starting the discussion on this JC. I'm torn. On the one hand, we /are/ supposed to be in feature freeze and jeez, can I ever get this thing out the door? Well, I'm going to try hard to do so as soon as possible. OTOH, this seems like such a useful and simple feature to add, it'd be almost a crime not to. What I would do is this: - If a post comes from a non-member, send a confirmation message to them. This would actually use most of the machinery already in place for confirmations. - If they confirm/reply, we'd add the address to the accept_these_nonmembers list and send all their held messages on through. Here's a question though: what do we do if the default moderation bit for members is turned on? I don't want to get into a situation where a member's posting would get held, but a non-member posting would go through without some interaction from the list owner. I guess if the default moderation bit is set, then we wouldn't send out the confirmation message, and non-member postings would have to be approved just like they are today. -Barry From barry@python.org Tue Jul 30 00:32:36 2002 From: barry@python.org (Barry A. Warsaw) Date: Mon, 29 Jul 2002 19:32:36 -0400 Subject: [Mailman-Developers] Re: Cute TMDA use References: <21784.1027735722@kanga.nu> Message-ID: <15685.53396.902107.91387@anthem.wooz.org> >>>>> "JRM" == Jason R Mastaler writes: JRM> Yup. One thing I also do is share an auto-whitelist among JRM> all the lists on my server. So, if claw@kanga.nu confirms JRM> his post to tmda-users, he'll instantly be able to post to JRM> tmda-workers as well. This makes things even more JRM> transparent for the end-user, particularly at sites hosting JRM> many lists. I agree this would be ideal, but I wouldn't do it for MM2.1. Certainly for MM3.0 when we have a federated user database, this makes perfect sense. -Barry From barry@python.org Tue Jul 30 00:34:56 2002 From: barry@python.org (Barry A. Warsaw) Date: Mon, 29 Jul 2002 19:34:56 -0400 Subject: [Mailman-Developers] Integrating TMDA (was Re: Cute TMDA use) References: <21784.1027735722@kanga.nu> Message-ID: <15685.53536.773032.572104@anthem.wooz.org> >>>>> "JRM" == Jason R Mastaler writes: JRM> I envision Mailman's web configuration interface making this JRM> very easy. A checkbox to toggle whether existing subscribers JRM> are allowed through, a textbox to enter explicitly JRM> blacklisted addresses, etc. I wouldn't change how postings from existing subscribers are handled. I think the most straightforward approach would be to simply use this as a way to seed the accept_these_nonmembers list, without admin intervention. JRM> Gravy like the "auto-whitelist" feature could be stolen from JRM> TMDA (also a pure-Python, GPL'd app) if necessary. JRM> I'd expect this to be no more than a few days work for JRM> someone intimately familiar with Mailman's source. Maybe a few hours. :) JRM> I don't know of any MLM with this functionality built-in, and JRM> it will virtually eliminate all spam. How's that for JRM> motivation? I'm hooked, but then I'm a push over. -Barry From barry@python.org Tue Jul 30 00:35:44 2002 From: barry@python.org (Barry A. Warsaw) Date: Mon, 29 Jul 2002 19:35:44 -0400 Subject: [Mailman-Developers] Integrating TMDA (was Re: Cute TMDA use) References: Message-ID: <15685.53584.128024.593976@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> Yup. And Barry's already made positive-sounding noises, but CVR> holding up release 2.1 to add this doesn't make sense. But CVR> making it a focus of 2.2 or 3.0 does. I think we need to CVR> finish 2.1, and then start the next round of enhancements. We CVR> don't want to get into "always another last featuer" mode. You've nailed me completely Chuq. ;) Not good, I know, but this one seems soooo easy. -Barry From barry@python.org Tue Jul 30 00:37:43 2002 From: barry@python.org (Barry A. Warsaw) Date: Mon, 29 Jul 2002 19:37:43 -0400 Subject: [Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use) References: <21784.1027735722@kanga.nu> <9508.1027922570@kanga.nu> <13773.1027963334@kanga.nu> Message-ID: <15685.53703.378405.962583@anthem.wooz.org> >> I'm comfortable with this as well, and don't mind making >> modifications to TMDA that would make this easier if that >> proves necessary. JCL> Not speaking for Barry, but there are large advantages to JCL> leveraging code that other people maintain vs increasing the JCL> code and maintenance load of Mailman. Absolutely, but I see this one as requiring very little extra new code so I /think/ we'd get it almost for free. Lemme see what a few hours of hacking tonight can produce. -Barry From JasonR.Mastaler Tue Jul 30 00:38:59 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Mon, 29 Jul 2002 17:38:59 -0600 Subject: [Mailman-Developers] Re: Cute TMDA use References: <21784.1027735722@kanga.nu> <15685.53396.902107.91387@anthem.wooz.org> Message-ID: barry@python.org (Barry A. Warsaw) writes: > I agree this would be ideal, but I wouldn't do it for MM2.1. Why not? Just because it would involve more changes than are appropriate for a release in beta? > Certainly for MM3.0 when we have a federated user database, this > makes perfect sense. I'm not familiar with a ``federated user database''. -- (http://tmda.net/) From kj@SerNet.DE Thu Jul 25 10:36:28 2002 From: kj@SerNet.DE (Krischan Jodies) Date: Thu, 25 Jul 2002 11:36:28 +0200 Subject: [Mailman-Developers] Make clobber_date default and configurable Message-ID: The default for clobber_date is "set time in archive to time of the date header of e-mail". I think the better default is to set the time to the resent time. At least this default should be configurable in mm_conf.py. Thanks, Krischan -- Service Network GmbH, mailto:kjodies@SerNet.DE, http://www.SerNet.DE phone: +49-551-370000-0, fax: +49-551-370000-9 From mjm@michaelmeltzer.com Wed Jul 24 18:39:48 2002 From: mjm@michaelmeltzer.com (Michael Meltzer) Date: Wed, 24 Jul 2002 13:39:48 -0400 Subject: [Mailman-Developers] A question about mime to links Message-ID: <00fd01c23339$1b82bae0$34f820c0@ix1x1000> For give me if this has come up before but I could not find much in a archive. I am running a small list with mailman/postfix, I would really like to demine/dehtml it for the digest users and the archive. The problem is I still want to support image attachments(maybe a few other types) to the email(the users like it :-). I had the great idea to convert the attachment to files and replace them in the email with a URL. I looked around and it seems 2.1 will handle the attachment issue but I am not sure about converting to links. SO: 1)changing to sendmail it out, so their goes mimedefang. 2)Any idea how to do this simply 3)it seem version 2.1 beta 2 has most of what I need, Anyone graftied in subport for what I need with the links. 4)Any Guidance how/where and what level in the code to add it myself 5)I will admint I am not an expert on mime, any show stoppers or "I am asking for it issues" MJM From sal@chainreactionweb.com Tue Jul 30 00:36:47 2002 From: sal@chainreactionweb.com (Salvatore F. Iozzia) Date: Mon, 29 Jul 2002 19:36:47 -0400 Subject: [Mailman-Developers] reminders References: <21784.1027735722@kanga.nu> <15685.53303.972678.484832@anthem.wooz.org> Message-ID: <048901c23758$cee3f1d0$08fea8c0@ReactorCore> I am trying to migrate a yahoo email list to my mailman list. One feature of yahoo is to send a reminder to the list of the weekly event the list is based on. Is there a way to do this with mailman, do I have to write a script in php or python and cron it? will mailman except email from the server and send them to the list? thanks for your time and responses. Salvatore Iozzia accelerator Chain Reaction Web - Guaranteed Hosting http://chainreactionweb.com Toll Free 866-994-7737 ----- Original Message ----- From: "Barry A. Warsaw" To: "J C Lawrence" Cc: Sent: Monday, July 29, 2002 7:31 PM Subject: Re: [Mailman-Developers] Cute TMDA use > > Very cool, thanks for starting the discussion on this JC. > > I'm torn. On the one hand, we /are/ supposed to be in feature freeze > and jeez, can I ever get this thing out the door? Well, I'm going to > try hard to do so as soon as possible. > > OTOH, this seems like such a useful and simple feature to add, it'd be > almost a crime not to. What I would do is this: > > - If a post comes from a non-member, send a confirmation message to > them. This would actually use most of the machinery already in > place for confirmations. > > - If they confirm/reply, we'd add the address to the > accept_these_nonmembers list and send all their held messages on > through. > > Here's a question though: what do we do if the default moderation bit > for members is turned on? I don't want to get into a situation where > a member's posting would get held, but a non-member posting would go > through without some interaction from the list owner. > > I guess if the default moderation bit is set, then we wouldn't send > out the confirmation message, and non-member postings would have to be > approved just like they are today. > > -Barry > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman-21/listinfo/mailman-developers > > From RossBoylan@stanfordalumni.org Sun Jul 28 22:27:41 2002 From: RossBoylan@stanfordalumni.org (Ross Boylan) Date: Sun, 28 Jul 2002 14:27:41 -0700 Subject: [Mailman-Developers] Some issues with the CVS head Message-ID: <20020728212741.GF2293@wheat.boylan.org> I just got the latest Mailman sources from CVS, and noticed a couple of things. 1) Required Python Version Some of the modules (e.g., DNS.py) require Python 2.2 (e.g., reference to email modules). Yet the readme says Python 2.1.3 or greater is required. The wiki http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/FrontPage says Python 2.0 will be required. This is of particular concern for me because I'm thinking of borrowing some parts for a Zope product, and Zope 2.5 uses Python 2.1 and reportedly will not work with 2.2. This is, of course, not a good reason for Mailman to stay on Python 2.1. I'm aware of the ZMailman project and sent a message to their list. However, what I'm doing probably goes in a different direction (I really just want the Bounce handling). 2) Code Inconsistencies Bouncer uses getBounceInfo. MemberAdaptor implements this (as well as OldMemberAdaptor), but MailingList doesn't inherit from it. So it looks as if everything is not quite hooked up yet. 3) A Stylistic Comment I also find it a little weird to see base classes making calls to methods that they don't define or inherit from, on the assumption that they will be mixed into something that does define them. It seems to me if this could be avoided, or at least if the classes could inherit from the classes with the relevant protocols, it would be cleaner. A lower tech approach would be to note the dependencies in class comments. But I think the inheritance might make the dependencies explicit while still preserving the ability to factor out chunks of functionality. 4) A Little Python Question Could anyone explain to me what this is doing? (e.g. from DNS.py) return filter(None, addrs) There are several uses of this filter(None,..) idiom in the code. The 2.0 code even says return filter(None, addrs) or None The docs for filter say the first argument should be a function, which None is not. When I try it, it seems to be a noop (i.e., filter(None, foo) == foo). And or'ing with None (false) also seems pointless. From transom@extremelogic.com Fri Jul 26 20:22:09 2002 From: transom@extremelogic.com (Todd Ransom) Date: Fri, 26 Jul 2002 15:22:09 -0400 Subject: [Mailman-Developers] mailman on windows/cygwin Message-ID: <000801c234d9$c2e26640$0b00a8c0@prometheus> Hello, I am putting together a document to describe the steps required to get = Mailman running on Windows 2000 using cygwin, exim and IIS. Just wanted = to see if you were interested in including this in the documentation or = on your web site. TR From wolf@adsl213063.vnet.hu Mon Jul 29 18:24:32 2002 From: wolf@adsl213063.vnet.hu (Romek =?iso-8859-1?Q?Kriszti=E1n?=) Date: Mon, 29 Jul 2002 19:24:32 +0200 Subject: [Mailman-Developers] TypeError: list objects are unhashable Message-ID: Hello! I use Python 2.2 and Mailman 2.0.12. I was using my copy of Mailman when I've experienced the following error: Jul 29 18:49:01 2002 qrunner(3629): Traceback (most recent call last): Jul 29 18:49:01 2002 qrunner(3629): File "/var/mailman/Mailman/Archiver/Archiver.py", line 221, in ArchiveMail Jul 29 18:49:01 2002 qrunner(3629): h.processUnixMailbox(f, HyperArch.Article) Jul 29 18:49:01 2002 qrunner(3629): File "/var/mailman/Mailman/Archiver/pipermail.py", line 528, in processUnixMailbox Jul 29 18:49:01 2002 qrunner(3629): self.add_article(a) Jul 29 18:49:01 2002 qrunner(3629): File "/var/mailman/Mailman/Archiver/HyperArch.py", line 917, in add_article Jul 29 18:49:01 2002 qrunner(3629): self._charsets[cs] = self._charsets.get(cs, 0) + 1 Jul 29 18:49:01 2002 qrunner(3629): TypeError: list objects are unhashable Jul 29 18:49:01 2002 (3629) CORRUPT ARCHIVE FOR LIST: listname This was when I sent my message to the list. After that I searched on Google about this problem. Somebody told to delete the pipermail.pck file in the archives directory. Okey, deleted. Next: my message was sent to everybody subscribed to the list, but I didn't find it in the archive list but one html file with numbers in the filename. Can you tell me something about what i am doing wrong and how can i fix this error? Krisztian Romek From JasonR.Mastaler Tue Jul 30 00:47:21 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Mon, 29 Jul 2002 17:47:21 -0600 Subject: [Mailman-Developers] Re: Cute TMDA use References: <21784.1027735722@kanga.nu> <15685.53303.972678.484832@anthem.wooz.org> Message-ID: barry@python.org (Barry A. Warsaw) writes: > Very cool, thanks for starting the discussion on this JC. This is a topic I brought up 6 months ago, but I guess I didn't speak loud enough . http://mail.python.org/pipermail-21/mailman-developers/2002-January/010404.html -- (http://tmda.net/) From barry@python.org Tue Jul 30 00:48:08 2002 From: barry@python.org (Barry A. Warsaw) Date: Mon, 29 Jul 2002 19:48:08 -0400 Subject: [Mailman-Developers] Re: Cute TMDA use References: <21784.1027735722@kanga.nu> <15685.53396.902107.91387@anthem.wooz.org> Message-ID: <15685.54328.886395.290464@anthem.wooz.org> >>>>> "JRM" == Jason R Mastaler writes: JRM> barry@python.org (Barry A. Warsaw) writes: >> I agree this would be ideal, but I wouldn't do it for MM2.1. JRM> Why not? Just because it would involve more changes than are JRM> appropriate for a release in beta? Yes, and because we currently have no database that's shared across mailing lists. Issues I don't want to think about include concurrent access to a shared database. >> Certainly for MM3.0 when we have a federated user database, >> this makes perfect sense. JRM> I'm not familiar with a ``federated user database''. One user database shared by all mailing lists. This will be the primary focus of Mailman 3.0. -Barry From chuqui@plaidworks.com Tue Jul 30 00:48:30 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 29 Jul 2002 16:48:30 -0700 Subject: [Mailman-Developers] Cute TMDA use In-Reply-To: <15685.53303.972678.484832@anthem.wooz.org> Message-ID: On 7/29/02 4:31 PM, "Barry A. Warsaw" wrote: > I guess if the default moderation bit is set, then we wouldn't send > out the confirmation message, and non-member postings would have to be > approved just like they are today. I would set things up so that they don't go into the moderation queue until they're confirmed, and then moderated as normal. The moderator stuff doesn't change, except that the moderator doesn't see them until the user confirms them. That closes the hole of the moderator having to deal with spam to the posting address. So basically, you put TMDA in front of the moderator, not replace the moderator in that case. The list is still moderated, just whitelisted THEN moderated. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Stress is when you wake up screaming and you realize you haven't fallen asleep yet. From barry@python.org Tue Jul 30 00:50:45 2002 From: barry@python.org (Barry A. Warsaw) Date: Mon, 29 Jul 2002 19:50:45 -0400 Subject: [Mailman-Developers] Make clobber_date default and configurable References: Message-ID: <15685.54485.177620.204564@anthem.wooz.org> >>>>> "KJ" == Krischan Jodies writes: KJ> The default for clobber_date is "set time in archive to time KJ> of the date header of e-mail". I think the better default is KJ> to set the time to the resent time. At least this default KJ> should be configurable in mm_conf.py. If we're talking about MM2.1, that's what the default clobber policy already does. -Barry From JasonR.Mastaler Tue Jul 30 00:56:17 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Mon, 29 Jul 2002 17:56:17 -0600 Subject: [Mailman-Developers] Re: Cute TMDA use References: <21784.1027735722@kanga.nu> <15685.53396.902107.91387@anthem.wooz.org> <15685.54328.886395.290464@anthem.wooz.org> Message-ID: barry@python.org (Barry A. Warsaw) writes: > Yes, and because we currently have no database that's shared across > mailing lists. Issues I don't want to think about include > concurrent access to a shared database. This assumes all the functionality is built into MM, rather than hooking TMDA into MM. In the latter case, it wouldn't matter whether MM had the shared db, as the lookup would come from an external source. -- (http://tmda.net/) From claw@kanga.nu Tue Jul 30 00:59:45 2002 From: claw@kanga.nu (J C Lawrence) Date: Mon, 29 Jul 2002 16:59:45 -0700 Subject: [Mailman-Developers] Cute TMDA use In-Reply-To: Message from Chuq Von Rospach of "Mon, 29 Jul 2002 16:48:30 PDT." References: Message-ID: <17429.1027987185@kanga.nu> On Mon, 29 Jul 2002 16:48:30 -0700 Chuq Von Rospach wrote: > On 7/29/02 4:31 PM, "Barry A. Warsaw" wrote: >> I guess if the default moderation bit is set, then we wouldn't send >> out the confirmation message, and non-member postings would have to >> be approved just like they are today. > I would set things up so that they don't go into the moderation queue > until they're confirmed, and then moderated as normal. The moderator > stuff doesn't change, except that the moderator doesn't see them until > the user confirms them. That closes the hole of the moderator having > to deal with spam to the posting address. So basically, you put TMDA > in front of the moderator, not replace the moderator in that case. The > list is still moderated, just whitelisted THEN moderated. Precisely. -- 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 JasonR.Mastaler Tue Jul 30 00:58:55 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Mon, 29 Jul 2002 17:58:55 -0600 Subject: [Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use) References: <21784.1027735722@kanga.nu> <9508.1027922570@kanga.nu> <13773.1027963334@kanga.nu> <15685.53703.378405.962583@anthem.wooz.org> Message-ID: barry@python.org (Barry A. Warsaw) writes: > Absolutely, but I see this one as requiring very little extra new > code so I /think/ we'd get it almost for free. Minus access to a shared confirmed senders list. This is surely better than nothing, but the shared list is a pretty integral feature IMO. I don't think I'd use the MM built-in support until this was available in some form. -- (http://tmda.net/) From barry@python.org Tue Jul 30 01:13:36 2002 From: barry@python.org (Barry A. Warsaw) Date: Mon, 29 Jul 2002 20:13:36 -0400 Subject: [Mailman-Developers] reminders References: <21784.1027735722@kanga.nu> <15685.53303.972678.484832@anthem.wooz.org> <048901c23758$cee3f1d0$08fea8c0@ReactorCore> Message-ID: <15685.55856.164800.181734@anthem.wooz.org> >>>>> "SFI" == Salvatore F Iozzia writes: SFI> I am trying to migrate a yahoo email list to my mailman SFI> list. One feature of yahoo is to send a reminder to the list SFI> of the weekly event the list is based on. Is there a way to SFI> do this with mailman, do I have to write a script in php or SFI> python and cron it? will mailman except email from the server SFI> and send them to the list? You can always set up a cron job that crafts the message and calls bin/inject to get the message delivered. Mailman 2.1, of course. -Barry From barry@python.org Tue Jul 30 01:24:11 2002 From: barry@python.org (Barry A. Warsaw) Date: Mon, 29 Jul 2002 20:24:11 -0400 Subject: [Mailman-Developers] Some issues with the CVS head References: <20020728212741.GF2293@wheat.boylan.org> Message-ID: <15685.56491.526857.98171@anthem.wooz.org> >>>>> "RB" == Ross Boylan writes: RB> Some of the modules (e.g., DNS.py) require Python 2.2 (e.g., RB> reference to email modules). Yet the readme says Python 2.1.3 RB> or greater is required. The wiki RB> http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/FrontPage RB> says Python 2.0 will be required. The wiki's out of date. Mailman 2.1 requires at least Python 2.1. The email package is backwards compatible with Python 2.1 and is distributed with Mailman so no worries there. RB> This is of particular concern for me because I'm thinking of RB> borrowing some parts for a Zope product, and Zope 2.5 uses RB> Python 2.1 and reportedly will not work with 2.2. This is, of RB> course, not a good reason for Mailman to stay on Python 2.1. I'm specifically not requiring Python 2.2 for Mailman 2.1, although I will likely require Python 2.2 for subsequent versions. Note that while Zope 2.5 and 2.6 can't officially claim to work with Python 2.2, we've had success with that combination. Zope 2.7 will require Python 2.2 at least. RB> Bouncer uses getBounceInfo. MemberAdaptor implements this (as RB> well as OldMemberAdaptor), but MailingList doesn't inherit RB> from it. So it looks as if everything is not quite hooked up RB> yet. Not quite correct. The membership database is a component of the MailList object, not a base class, although MailList delegates membership method calls to its MemberAdaptor instance (in the default case, an OldStyleMemberships instance). RB> I also find it a little weird to see base classes making calls RB> to methods that they don't define or inherit from, on the RB> assumption that they will be mixed into something that does RB> define them. Why? Seems like classic mixin design to me. I'm not saying I'm crazy about the mixin design of the MailList class, but there's nothing weird going on. Now the delegation to the MemberAdaptor instance /is/ slightly idiosyncratic but it's not too strange. RB> It seems to me if this could be avoided, or at RB> least if the classes could inherit from the classes with the RB> relevant protocols, it would be cleaner. A lower tech RB> approach would be to note the dependencies in class comments. RB> But I think the inheritance might make the dependencies RB> explicit while still preserving the ability to factor out RB> chunks of functionality. Hmm. I have a strong desire to use Zope's Interface package (which by that time might make it into Python) to be very explicit about the pluggable components in the system. That's for a future release though. RB> 4) A Little Python Question RB> Could anyone explain to me what this is doing? (e.g. from RB> DNS.py) return filter(None, addrs) There are several uses of RB> this filter(None,..) idiom in the code. | The 2.0 code even says | return filter(None, addrs) or None RB> The docs for filter say the first argument should be a RB> function, which None is not. When I try it, it seems to be a RB> noop (i.e., filter(None, foo) == foo). And or'ing with None RB> (false) also seems pointless. >From the Python 2.2 docs: filter(function, list) Construct a list from those elements of list for which function returns true. list may be either a sequence, a container which supports iteration, or an iterator, If list is a string or a tuple, the result also has that type; otherwise it is always a list. If function is None, the identity function is assumed, that is, all elements of list that are false (zero or empty) are removed. So "filter(None, addrs)" just removes the false elements from the list. A more modern Pythonic way to spell this would be with a list comprehension: return [x for x in addrs if x] Makes more sense too! :) -Barry From barry@python.org Tue Jul 30 01:24:50 2002 From: barry@python.org (Barry A. Warsaw) Date: Mon, 29 Jul 2002 20:24:50 -0400 Subject: [Mailman-Developers] mailman on windows/cygwin References: <000801c234d9$c2e26640$0b00a8c0@prometheus> Message-ID: <15685.56530.471795.821573@anthem.wooz.org> >>>>> "TR" == Todd Ransom writes: TR> I am putting together a document to describe the steps TR> required to get Mailman running on Windows 2000 using cygwin, TR> exim and IIS. Just wanted to see if you were interested in TR> including this in the documentation or on your web site. Absolutely! Send me a link when the docs are ready. I'd also suggest adding something to the Mailman FAQ. -Barry From barry@python.org Tue Jul 30 01:27:42 2002 From: barry@python.org (Barry A. Warsaw) Date: Mon, 29 Jul 2002 20:27:42 -0400 Subject: [Mailman-Developers] Re: Cute TMDA use References: <21784.1027735722@kanga.nu> <15685.53303.972678.484832@anthem.wooz.org> Message-ID: <15685.56702.673027.659616@anthem.wooz.org> >>>>> "JRM" == Jason R Mastaler writes: JRM> barry@python.org (Barry A. Warsaw) writes: >> Very cool, thanks for starting the discussion on this JC. JRM> This is a topic I brought up 6 months ago, but I guess I JRM> didn't speak loud enough . JRM> http://mail.python.org/pipermail-21/mailman-developers/2002-January/010404.html At the time, I don't think I realized the implications of what you were putting together. My bad. Still, it's darn cool! :) -Barry From JasonR.Mastaler Tue Jul 30 01:34:18 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Mon, 29 Jul 2002 18:34:18 -0600 Subject: [Mailman-Developers] Re: Cute TMDA use References: <21784.1027735722@kanga.nu> <15685.53303.972678.484832@anthem.wooz.org> <15685.56702.673027.659616@anthem.wooz.org> Message-ID: barry@python.org (Barry A. Warsaw) writes: > At the time, I don't think I realized the implications of what you > were putting together. My bad. Still, it's darn cool! :) Better late than never . -- (http://tmda.net/) From barry@python.org Tue Jul 30 01:35:06 2002 From: barry@python.org (Barry A. Warsaw) Date: Mon, 29 Jul 2002 20:35:06 -0400 Subject: [Mailman-Developers] Re: Cute TMDA use References: <21784.1027735722@kanga.nu> <15685.53396.902107.91387@anthem.wooz.org> <15685.54328.886395.290464@anthem.wooz.org> Message-ID: <15685.57146.549691.979037@anthem.wooz.org> >>>>> "JRM" == Jason R Mastaler writes: >> Yes, and because we currently have no database that's shared >> across mailing lists. Issues I don't want to think about >> include concurrent access to a shared database. JRM> This assumes all the functionality is built into MM, rather JRM> than hooking TMDA into MM. In the latter case, it wouldn't JRM> matter whether MM had the shared db, as the lookup would come JRM> from an external source. So if we /don't/ build the functionality into MM2.1 (as Chuq is so sensibly arguing :) is there anything we need to do to implement the whitelisting TMDA fronted MM that is being proposed here? If so, let's talk about that. If not, maybe we're done. :) -Barry From barry@python.org Tue Jul 30 01:37:21 2002 From: barry@python.org (Barry A. Warsaw) Date: Mon, 29 Jul 2002 20:37:21 -0400 Subject: [Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use) References: <21784.1027735722@kanga.nu> <9508.1027922570@kanga.nu> <13773.1027963334@kanga.nu> <15685.53703.378405.962583@anthem.wooz.org> Message-ID: <15685.57281.971918.783688@anthem.wooz.org> >>>>> "JRM" == Jason R Mastaler writes: >> Absolutely, but I see this one as requiring very little extra >> new code so I /think/ we'd get it almost for free. JRM> Minus access to a shared confirmed senders list. JRM> This is surely better than nothing, but the shared list is a JRM> pretty integral feature IMO. I don't think I'd use the MM JRM> built-in support until this was available in some form. I have to defer to you and others who have actually started using this arrangement. If what you say is the case -- builtin support isn't terribly useful without the shared whitelist -- then maybe it does make sense to defer until a later Mailman version. If MM+TMDA does the job, then that's probably good enough. -Barry From chuqui@plaidworks.com Tue Jul 30 01:42:14 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 29 Jul 2002 17:42:14 -0700 Subject: [Mailman-Developers] Re: Cute TMDA use In-Reply-To: <15685.57146.549691.979037@anthem.wooz.org> Message-ID: On 7/29/02 5:35 PM, "Barry A. Warsaw" wrote: > So if we /don't/ build the functionality into MM2.1 (as Chuq is so > sensibly arguing :) is there anything we need to do to implement the > whitelisting TMDA fronted MM that is being proposed here? -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ No! No! Dead girl, OFF the table! -- Shrek From barry@python.org Tue Jul 30 03:29:29 2002 From: barry@python.org (Barry A. Warsaw) Date: Mon, 29 Jul 2002 22:29:29 -0400 Subject: [Mailman-Developers] Cute TMDA use References: <15685.53303.972678.484832@anthem.wooz.org> Message-ID: <15685.64009.863090.384577@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: >> I guess if the default moderation bit is set, then we wouldn't >> send out the confirmation message, and non-member postings >> would have to be approved just like they are today. CVR> I would set things up so that they don't go into the CVR> moderation queue until they're confirmed, and then moderated CVR> as normal. The moderator stuff doesn't change, except that CVR> the moderator doesn't see them until the user confirms CVR> them. That closes the hole of the moderator having to deal CVR> with spam to the posting address. So basically, you put TMDA CVR> in front of the moderator, not replace the moderator in that CVR> case. The list is still moderated, just whitelisted THEN CVR> moderated. Ah wait, I see what you're suggesting. A confirmed non-member wouldn't get added to accept_these_nonmembers, but their message would not show up in the admindb until they've confirmed. The messages would be in a sort of limbo until them, with timeout/auto-discards if they don't confirm after a certain amount of time. Once they've confirmed, we'll do the normal non-member action (although it would make little sense to go through this rigamarole if we're simply discarding or rejecting non-member postings). Maybe the admindb should have a button that would let them see all held message, including non-confirmed ones? Perhaps that's a YAGNI. Have I got that right? I'll think on it and try to decide whether it's worth adding to 2.1 or not. -Barry From JasonR.Mastaler Tue Jul 30 03:55:27 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Mon, 29 Jul 2002 20:55:27 -0600 Subject: [Mailman-Developers] Re: Cute TMDA use References: <21784.1027735722@kanga.nu> <15685.53396.902107.91387@anthem.wooz.org> <15685.54328.886395.290464@anthem.wooz.org> <15685.57146.549691.979037@anthem.wooz.org> Message-ID: barry@python.org (Barry A. Warsaw) writes: > So if we /don't/ build the functionality into MM2.1 (as Chuq is so > sensibly arguing :) is there anything we need to do to implement the > whitelisting TMDA fronted MM that is being proposed here? I think we just need documentation. I've only ever combined MM and TMDA under qmail, and it's quite easy. Given .qmail-list which posts to the list, you just need to edit and add the following to the top of the file: |preline /usr/bin/tmda-filter Then make a symlink from .qmail-list-confirm-default to .qmail-list. A FAQ entry with this along with some configuration suggestions would satisfy that. Perhaps I'll do this tomorrow. Non-qmail MTAs aren't as flexible, so perhaps JC can comment on his experiences? In any case, I think the necessary changes (if any) would go into TMDA and not MM. So, perhaps you are done. -- (http://tmda.net/) From JasonR.Mastaler Tue Jul 30 04:02:25 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Mon, 29 Jul 2002 21:02:25 -0600 Subject: [Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use) References: <21784.1027735722@kanga.nu> <9508.1027922570@kanga.nu> <13773.1027963334@kanga.nu> <15685.53703.378405.962583@anthem.wooz.org> <15685.57281.971918.783688@anthem.wooz.org> Message-ID: barry@python.org (Barry A. Warsaw) writes: > If what you say is the case -- builtin support isn't terribly useful > without the shared whitelist -- then maybe it does make sense to > defer until a later Mailman version. Some users will not want to use a shared whitelist, but in my experience, the vast majority will. I predict that if you add the feature without this sub-feature, it will become a nagging FAQ. Think about a site with 1000 mailing lists. User jdoe is subscribed to 2 of these lists, but over time starts posting to others. He'll get very tired of confirming his message upwards of 998 times. And this assumes he only uses a single e-mail address. It's also more difficult from a management perspective. Instead of having one data-store to prune, you have 1000. I can't actually think of a good reason why you'd ever NOT want to utilize a shared whitelist. The goal is to keep spammers out, not to impede legitimate senders. In a perfect universe, you'd have a global whitelist containing the address of every non-spammer on the planet. :-) -- (http://tmda.net/) From dmick@utopia.West.Sun.COM Tue Jul 30 04:06:49 2002 From: dmick@utopia.West.Sun.COM (Dan Mick) Date: Mon, 29 Jul 2002 20:06:49 -0700 (PDT) Subject: [Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use) Message-ID: <200207300306.g6U36mOl011491@utopia.West.Sun.COM> > JRM> This is surely better than nothing, but the shared list is a > JRM> pretty integral feature IMO. I don't think I'd use the MM > JRM> built-in support until this was available in some form. > > I have to defer to you and others who have actually started using this > arrangement. If what you say is the case -- builtin support isn't > terribly useful without the shared whitelist -- then maybe it does > make sense to defer until a later Mailman version. If MM+TMDA does > the job, then that's probably good enough. Why does it matter? Doesn't that just cause the user to go through N confirmations per server instead of 1, but since the confirmations are nearly free, who cares?... Probably missing something again. But I'm on very few lists that share a server, so I'd expect the normal behavior of "one confirm per list per alien address" behavior anyway (I think the only multilist server I communicate with is python.org). From ping@zesty.ca Tue Jul 30 03:53:15 2002 From: ping@zesty.ca (Ka-Ping Yee) Date: Mon, 29 Jul 2002 19:53:15 -0700 (PDT) Subject: [Mailman-Developers] Re: Opening up a few can o' worms here... Message-ID: Barry wrote: > Do you want to attempt to obscure the > address (e.g. "barry--at--python--dot--org") Chuq wrote: > Anything you programmatically obscure will be programmatically > de-obscured. I don't think this is entirely true. This is probably true if you invent ways of rearranging text that is still readable as an e-mail address, but one possible good solution is to use an image instead. If you generate an image containing the entire e-mail address, it can be made extremely hard to read, even with state-of-the-art OCR. And it raises the bar so high that it will be a long time before spammers bother to even try OCR -- it's much too easy to harvest addresses in other, simpler ways. Just to give you an idea of what tricks are possible: a GIF can contain many different colour table entries that map to almost the same colour; the background can be patterned; the text can be distorted or blurred; the text can be drawn shadowed or embossed; the text can be broken into multiple frames of a GIF animation; etc. etc. Many of these things can be done subtly enough that the text is still trivial for anyone to read, yet it becomes phenomenally difficult for a machine to decode -- to the point where the spammer's best bet is to take a video capture of the screen, print it out, run it through a scanner, and run a fancy OCR program on the result. -- ?!ng From barry@python.org Tue Jul 30 04:17:22 2002 From: barry@python.org (Barry A. Warsaw) Date: Mon, 29 Jul 2002 23:17:22 -0400 Subject: [Mailman-Developers] Re: Cute TMDA use References: <21784.1027735722@kanga.nu> <15685.53396.902107.91387@anthem.wooz.org> <15685.54328.886395.290464@anthem.wooz.org> <15685.57146.549691.979037@anthem.wooz.org> Message-ID: <15686.1346.837824.302027@anthem.wooz.org> >>>>> "JRM" == Jason R Mastaler writes: JRM> In any case, I think the necessary changes (if any) would go JRM> into TMDA and not MM. So, perhaps you are done. Sounds good. Also, I guess a TMDA Howto could be added. I should probably also include a link to any TMDA documentation on the subject, when I overhaul MM's documentation . -Barry From barry@python.org Tue Jul 30 04:21:57 2002 From: barry@python.org (Barry A. Warsaw) Date: Mon, 29 Jul 2002 23:21:57 -0400 Subject: [Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use) References: <21784.1027735722@kanga.nu> <9508.1027922570@kanga.nu> <13773.1027963334@kanga.nu> <15685.53703.378405.962583@anthem.wooz.org> <15685.57281.971918.783688@anthem.wooz.org> Message-ID: <15686.1621.817286.23809@anthem.wooz.org> >>>>> "JRM" == Jason R Mastaler writes: JRM> Some users will not want to use a shared whitelist, but in my JRM> experience, the vast majority will. I predict that if you JRM> add the feature without this sub-feature, it will become a JRM> nagging FAQ. JRM> Think about a site with 1000 mailing lists. User jdoe is JRM> subscribed to 2 of these lists, but over time starts posting JRM> to others. He'll get very tired of confirming his message JRM> upwards of 998 times. And this assumes he only uses a single JRM> e-mail address. JRM> It's also more difficult from a management perspective. JRM> Instead of having one data-store to prune, you have 1000. It's a persuasive argument. I'm already dreading the integration problem when you try to federate the member databases of those 1000 lists. Adding another list of addresses that need to be collated could be another headache. OTOH, since the whitelist is /only/ a list of addresses, a simple union would probably suffice (you don't have the same problem with unioning member database since non-members don't have option flags and other data). JRM> I can't actually think of a good reason why you'd ever NOT JRM> want to utilize a shared whitelist. The goal is to keep JRM> spammers out, not to impede legitimate senders. In a perfect JRM> universe, you'd have a global whitelist containing the JRM> address of every non-spammer on the planet. :-) So when are you going to start collating the whitelists from all the TMDA sites and sell the opt-inside-out lists? :) -Barry From barry@python.org Tue Jul 30 04:23:12 2002 From: barry@python.org (Barry A. Warsaw) Date: Mon, 29 Jul 2002 23:23:12 -0400 Subject: [Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use) References: <200207300306.g6U36mOl011491@utopia.West.Sun.COM> Message-ID: <15686.1696.466027.28317@anthem.wooz.org> >>>>> "DM" == Dan Mick writes: DM> Probably missing something again. But I'm on very few lists DM> that share a server, so I'd expect the normal behavior of "one DM> confirm per list per alien address" behavior anyway (I think DM> the only multilist server I communicate with is python.org). For me, it's python.org, zope.org (they're really shared anyway), and SourceForge. I'd dearly love one user account -- and one admin account for all the lists on p.o/z.o. -Barry From JasonR.Mastaler Tue Jul 30 04:27:15 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Mon, 29 Jul 2002 21:27:15 -0600 Subject: [Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use) References: <21784.1027735722@kanga.nu> <9508.1027922570@kanga.nu> <13773.1027963334@kanga.nu> <15685.53703.378405.962583@anthem.wooz.org> <15685.57281.971918.783688@anthem.wooz.org> <15686.1621.817286.23809@anthem.wooz.org> Message-ID: barry@python.org (Barry A. Warsaw) writes: > So when are you going to start collating the whitelists from all the > TMDA sites and sell the opt-inside-out lists? :) You want in? -- (http://tmda.net/) From chuqui@plaidworks.com Tue Jul 30 04:30:19 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 29 Jul 2002 20:30:19 -0700 Subject: [Mailman-Developers] Re: Opening up a few can o' worms here... In-Reply-To: Message-ID: On 7/29/02 7:53 PM, "Ka-Ping Yee" wrote: > If you generate an image containing the entire e-mail address, it > can be made extremely hard to read, even with state-of-the-art OCR. Hard to read isn't enough. That was the essential failing of slashdot's attempt to do the "we'll choose a random algorithm for the address". It forgets that spammers don't need to read it all the time. It only needs to read it ONCE. So "hard to read" merely slows them down, once they decide to start harvesting that stuff. It doesn't stop them, and since it's all automated, they don't care if it takes them ten passes across your system to get 50% of your addresses or 5 passes to get 80%. They still win. > And it raises the bar so high that it will be a long time before > spammers bother to even try OCR -- it's much too easy to harvest > addresses in other, simpler ways. That makes me feel better. But seriously, that's "the club" philosophy. Make your car enough harder to steal that they go steal someone else's. Works fine, until either the other cars get smart and use the clubs, also, the other cars are all stolen, or the guy stealing cars decides he really wants your car and it's worth the effort. In other words, that's no solution at all. Just a delaying tactic. And the more people who adopt it, the faster it'll get cracked by the bots. So the real answer is to find a way to "raise the bar" that really sucks, so nobody else adopts it... > Just to give you an idea of what tricks are possible: a GIF can > contain many different colour table entries that map to almost the > same colour; the background can be patterned; the text can be > distorted or blurred; the text can be drawn shadowed or embossed; And I'll bet in most of those situations, you just made your web site none-ADA compliant. Which means it's a no-go for a lot of sites where accessibility is necessary. Actually, now that I think about it, the simple use of the graphic iwthout an acceptable ALT tag (which defeats the purpose of the graphic) makes this non-compliant with ADA for sight-limited people who use reader apps. That, right there, makes it a no-op for many sites. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Very funny, Scotty. Now beam my clothes down here, will you? From JasonR.Mastaler Tue Jul 30 04:32:39 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Mon, 29 Jul 2002 21:32:39 -0600 Subject: [Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use) References: <200207300306.g6U36mOl011491@utopia.West.Sun.COM> Message-ID: Dan Mick writes: > (I think the only multilist server I communicate with is > python.org). A few that I can think of offhand that I use, some of which host a f'ton of lists: python.org, mail.kde.org, sourceforge, mail.gnu.org, listman.redhat.com. -- (http://tmda.net/) From noreply@sourceforge.net Tue Jul 30 05:33:22 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 29 Jul 2002 21:33:22 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-588373 ] bug with 2.1b2 (something with cookies?) Message-ID: Bugs item #588373, was opened at 2002-07-29 23:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=588373&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Marshall (paulmarshll) Assigned to: Nobody/Anonymous (nobody) Summary: bug with 2.1b2 (something with cookies?) Initial Comment: This is hopefully my third and final stupid question involving mailman. I have mailman 2.1b2 setup and mostly working (I can create lists, and post, etc...). However whenever I try to log into a list via the admin page to edit/delete/whatever to it, it comes up with this bug: Traceback (most recent call last): File "/var/mailman/scripts/driver", line 82, in run_main main() File "/var/mailman/Mailman/Cgi/admin.py", line 82, in main cgidata.getvalue('adminpw', '')): File "/var/mailman/Mailman/SecurityManager.py", line 208, in WebAuthenticate print self.MakeCookie(ac, user) File "/var/mailman/Mailman/SecurityManager.py", line 223, in MakeCookie c = Cookie.SimpleCookie() AttributeError: 'module' object has no attribute 'SimpleCookie' Is this a permissions problem? something to do with creating cookies...Honestly, I have no idea... I've searched some bug databases and most likely passed right over it, however I can't seem to find anything dealing with this error. Thanks for all the help. Paul ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=588373&group_id=103 From jwblist@olympus.net Tue Jul 30 06:19:32 2002 From: jwblist@olympus.net (John W Baxter) Date: Mon, 29 Jul 2002 22:19:32 -0700 Subject: [Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use) In-Reply-To: References: <21784.1027735722@kanga.nu> <9508.1027922570@kanga.nu> <13773.1027963334@kanga.nu> <15685.53703.378405.962583@anthem.wooz.org> <15685.57281.971918.783688@anthem.wooz.org> Message-ID: At 21:02 -0600 7/29/2002, Jason R. Mastaler wrote: >In a perfect universe, you'd have a global >whitelist containing the address of every non-spammer on the planet. In a perfect universe, there would be no spammers on the planet. ;-) --John -- John W. Baxter Port Ludlow, WA, USA set emptyRecord to {behindTheCurtain: "Pay no attention to the string behind the curtain!"} From jwblist@olympus.net Tue Jul 30 06:26:55 2002 From: jwblist@olympus.net (John W Baxter) Date: Mon, 29 Jul 2002 22:26:55 -0700 Subject: [Mailman-Developers] Re: Opening up a few can o' worms here... In-Reply-To: References: Message-ID: At 19:53 -0700 7/29/2002, Ka-Ping Yee wrote: >If you generate an image containing the entire e-mail address, it >can be made extremely hard to read, even with state-of-the-art OCR. It also becomes hard to read for those who don't have their browser download images. Plus you have to avoid typical ad sizes. --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From claw@kanga.nu Tue Jul 30 08:06:53 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 30 Jul 2002 00:06:53 -0700 Subject: [Mailman-Developers] Cute TMDA use In-Reply-To: Message from barry@python.org (Barry A. Warsaw) of "Mon, 29 Jul 2002 22:29:29 EDT." <15685.64009.863090.384577@anthem.wooz.org> References: <15685.53303.972678.484832@anthem.wooz.org> <15685.64009.863090.384577@anthem.wooz.org> Message-ID: <20407.1028012813@kanga.nu> On Mon, 29 Jul 2002 22:29:29 -0400 Barry A Warsaw wrote: > Maybe the admindb should have a button that would let them see all > held message, including non-confirmed ones? Perhaps that's a YAGNI. I'd certainly like and use such a feature. -- 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 claw@kanga.nu Tue Jul 30 08:19:15 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 30 Jul 2002 00:19:15 -0700 Subject: [Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use) In-Reply-To: Message from barry@python.org (Barry A. Warsaw) of "Mon, 29 Jul 2002 20:37:21 EDT." <15685.57281.971918.783688@anthem.wooz.org> References: <21784.1027735722@kanga.nu> <9508.1027922570@kanga.nu> <13773.1027963334@kanga.nu> <15685.53703.378405.962583@anthem.wooz.org> <15685.57281.971918.783688@anthem.wooz.org> Message-ID: <20632.1028013555@kanga.nu> On Mon, 29 Jul 2002 20:37:21 -0400 Barry A Warsaw wrote: > I have to defer to you and others who have actually started using this > arrangement. If what you say is the case -- builtin support isn't > terribly useful without the shared whitelist -- then maybe it does > make sense to defer until a later Mailman version. If MM+TMDA does > the job, then that's probably good enough. Given your prior comments and a brief review on this end of the relevant effort required: Have we now spent more time and effort on discussing this than would have been required to just do it? -- 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@plaidworks.com Tue Jul 30 08:18:47 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 30 Jul 2002 00:18:47 -0700 Subject: [Mailman-Developers] Off topic: a cautionary tale. Message-ID: Just because it's too much fun to not pass along, and a useful cautionary tale. Fortunately, the person this happened to has a sense of humor about it... A friend of mine was working on his home web site. It was a bunch of stuff, back-ended by mySQL. He was, for instance, installing a search engine (using htDig) for the content, but it wasn't cooperating and he was trying to figure out why. Suddenly, the site goes dark. He can't log into it. He starts snooping, he can't get into MySQL. Uh, oh. (oh. No backups, either). The entire site implodes. He finally gives up, goes into the web logs to see what happens, thinking he got hacked. Well, not quite. One of the tools he installed was phpMyAdmin to administer the MySQL stuff. He installed it behind a .htaccess file like you're supposed to. But what he didn't realize was the .htaccess file wasn't working right, letting anything in. What got in was -- htDig, the search engine. Which happily follows all links, including, if you let it spider phpMyAdmin, the "delete this database" links. Including the database holding all of the MySQL configuration and account info. Which causes MySQL to die. Which... You get the picture. His search engine got into his database and deleted all of his data, because while it wasn't working, it COULD spider. And it got into an area it shouldn't have gotten into, even though it wasn't linked on the web site. How's that, you ask? How did HtDIG find it? Well -- one of the other things he'd added was log processing. Including referer tracking. And one of the links the logs showed was a referer link back to the phpMyAdmin pages. So by spidering the web log data, HtDIG found a link into phpMyAdmin, which was supposed to be password protected but wasn't, which let htDig become a DBA, which let HtDIG delete all of the data... When you build systems, do you think through the side effects of what you're doing? What are you missing? (and would you have ever figured out why this happened to you? I wonder if I would have.... ) Happy hacking... But be careful out there. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after From claw@kanga.nu Tue Jul 30 08:25:08 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 30 Jul 2002 00:25:08 -0700 Subject: [Mailman-Developers] Re: Cute TMDA use In-Reply-To: Message from Jason R.Mastaler of "Mon, 29 Jul 2002 20:55:27 MDT." References: <21784.1027735722@kanga.nu> <15685.53396.902107.91387@anthem.wooz.org> <15685.54328.886395.290464@anthem.wooz.org> <15685.57146.549691.979037@anthem.wooz.org> Message-ID: <20727.1028013908@kanga.nu> On Mon, 29 Jul 2002 20:55:27 -0600 Jason R Mastaler wrote: > barry@python.org (Barry A. Warsaw) writes: >> So if we /don't/ build the functionality into MM2.1 (as Chuq is so >> sensibly arguing :) is there anything we need to do to implement the >> whitelisting TMDA fronted MM that is being proposed here? > I think we just need documentation. I've only ever combined MM and > TMDA under qmail, and it's quite easy. Given .qmail-list which posts > to the list, you just need to edit and add the following to the top of > the file: I have TMDA+Mailman (with MIME filters and other niceties) working under Exim. Doing the same under Postfix is a bit of a bitch due to effective UID/GID problems for executing pipe, but can be solved with the vtable trick detailed in the Postfix README. If you decide _NOT_ to roll TMDA-like features into v2.1 I'll continue with my project and should post documentation, scripts, and other relevant bits here in the next week or so. > Non-qmail MTAs aren't as flexible, so perhaps JC can comment on his > experiences? Mostly its as commented here and on the TMDA lists (macro limitations etc). There's a little problem with effective UID/GID for gaining access to the Mailman config.db, but that's a trivial problem under Exim if you follow the Exim HowTo as a base model. > In any case, I think the necessary changes (if any) would go into TMDA > and not MM. So, perhaps you are done. Yeah, plus a little plugin logic (eg web UI). -- 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 claw@kanga.nu Tue Jul 30 08:26:57 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 30 Jul 2002 00:26:57 -0700 Subject: [Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use) In-Reply-To: Message from Jason R.Mastaler of "Mon, 29 Jul 2002 21:02:25 MDT." References: <21784.1027735722@kanga.nu> <9508.1027922570@kanga.nu> <13773.1027963334@kanga.nu> <15685.53703.378405.962583@anthem.wooz.org> <15685.57281.971918.783688@anthem.wooz.org> Message-ID: <20756.1028014017@kanga.nu> On Mon, 29 Jul 2002 21:02:25 -0600 Jason R Mastaler wrote: > barry@python.org (Barry A. Warsaw) writes: >> If what you say is the case -- builtin support isn't terribly useful >> without the shared whitelist -- then maybe it does make sense to >> defer until a later Mailman version. > Some users will not want to use a shared whitelist, but in my > experience, the vast majority will. I predict that if you add the > feature without this sub-feature, it will become a nagging FAQ. At its root its a privacy and entrance notification problem. Its not so much that the whitelist is private, but that entering it for discrete list populations is a hard edged and published (to the list owner or subscriber base) event, as distinct from the global whitelist. -- 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 claw@kanga.nu Tue Jul 30 08:29:37 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 30 Jul 2002 00:29:37 -0700 Subject: [Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use) In-Reply-To: Message from Dan Mick of "Mon, 29 Jul 2002 20:06:49 PDT." <200207300306.g6U36mOl011491@utopia.West.Sun.COM> References: <200207300306.g6U36mOl011491@utopia.West.Sun.COM> Message-ID: <20791.1028014177@kanga.nu> On Mon, 29 Jul 2002 20:06:49 -0700 (PDT) Dan Mick wrote: > Probably missing something again. But I'm on very few lists that > share a server, so I'd expect the normal behavior of "one confirm per > list per alien address" behavior anyway (I think the only multilist > server I communicate with is python.org). SourceForge is the other canonical case. Note: SF is likely going to have severe performance problems with the current flatfile list implementation. Odds are that they're going to want a persistent SQL-backed implementation due to their size. :nudges Marc. -- 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 claw@kanga.nu Tue Jul 30 08:32:43 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 30 Jul 2002 00:32:43 -0700 Subject: [Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use) In-Reply-To: Message from barry@python.org (Barry A. Warsaw) of "Mon, 29 Jul 2002 20:37:21 EDT." <15685.57281.971918.783688@anthem.wooz.org> References: <21784.1027735722@kanga.nu> <9508.1027922570@kanga.nu> <13773.1027963334@kanga.nu> <15685.53703.378405.962583@anthem.wooz.org> <15685.57281.971918.783688@anthem.wooz.org> Message-ID: <20823.1028014363@kanga.nu> On Mon, 29 Jul 2002 20:37:21 -0400 Barry A Warsaw wrote: > If MM+TMDA does the job, then that's probably good enough. While I like the idea of TMDA-like features built into MM, I like the plugin model even more. Among the deciding factors for me is tht I'd like to expose some of the other TMDA-features like dated addresses, sender address etc into Mailman lists (eg the prior commentary on lists which hide poster addresses with TMDA-based dated addresses). It suspect would be significantly easier to bolt that atop a TMDA-based Mailman plugin than it would be to bolt it onto Mailman+TMDA-like features. -- 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 Donal.Hunt2@mail.dcu.ie Tue Jul 30 10:01:22 2002 From: Donal.Hunt2@mail.dcu.ie (Donal Hunt) Date: Tue, 30 Jul 2002 10:01:22 +0100 Subject: [Mailman-Developers] Cute TMDA use Message-ID: <3D4655E2.74D82F1E@mail.dcu.ie> mailman-developers-request@python.org wrote: ------------------------------------------------------------------------ > Subject: Re: [Mailman-Developers] Cute TMDA use > Date: Mon, 29 Jul 2002 22:29:29 -0400 > From: barry@python.org (Barry A. Warsaw) > To: Chuq Von Rospach > CC: J C Lawrence , > References: <15685.53303.972678.484832@anthem.wooz.org> > > > Ah wait, I see what you're suggesting. A confirmed non-member > wouldn't get added to accept_these_nonmembers, but their message would > not show up in the admindb until they've confirmed. > > The messages would be in a sort of limbo until them, with > timeout/auto-discards if they don't confirm after a certain amount of > time. Once they've confirmed, we'll do the normal non-member action > (although it would make little sense to go through this rigamarole if > we're simply discarding or rejecting non-member postings). > > Maybe the admindb should have a button that would let them see all > held message, including non-confirmed ones? Perhaps that's a YAGNI. > > Have I got that right? I'll think on it and try to decide whether > it's worth adding to 2.1 or not. > > -Barry > > ------------------------------------------------------------------------ The above would be great!! We currently have a problem with students (university environment) sending "spam" to hundreds of lists so they can find a room mate!! We've stopped it by reducing the number of lists a person can post to at the same time. However, the side effect is that the list admin (one for all the student lists) gets mailed hundreds of times because there is one pending message for each list!!! So we wrote a script to clear the pending messages log. :) The above would be fierce handy as the list admin wouldn't get mailed about unconfirmed emails until they were confirmed... And if someone got 200+ confirmation mails it's unlikely the messages would ever be seen by the list admin. "This would be a good thing"(tm). :) The central userbase (if it included the admins too) would mean admins would get one email about all the pending messages for their lists and perhaps one webpage for confirming/rejecting (ie multiple list all on the same page / login) would be excellent too. Anyway... that's further down the road - let's keep our eye on the 2.1 ball!! Donal DCU From ping@zesty.ca Tue Jul 30 11:41:15 2002 From: ping@zesty.ca (Ka-Ping Yee) Date: Tue, 30 Jul 2002 03:41:15 -0700 (PDT) Subject: [Mailman-Developers] Re: Opening up a few can o' worms here... In-Reply-To: Message-ID: On Mon, 29 Jul 2002, Chuq Von Rospach wrote: > Hard to read isn't enough. That was the essential failing of slashdot's > attempt to do the "we'll choose a random algorithm for the address". It > forgets that spammers don't need to read it all the time. It only needs to > read it ONCE. So "hard to read" merely slows them down, once they decide to > start harvesting that stuff. It doesn't stop them, and since it's all > automated, they don't care if it takes them ten passes across your system to > get 50% of your addresses or 5 passes to get 80%. They still win. I think they'd hardly be able to get any. Have you really thought about how hard this would be? Why would they bother to invest the enormous development effort to make this work for the one or two addresses they *might* get, along with a large number of misread addresses? > In other words, that's no solution at all. Just a delaying tactic. And the > more people who adopt it, the faster it'll get cracked by the bots. No, the simple textual obfuscation methods are what count as delaying tactics. A human can look at "barry at zope dot org" just once and write down a program for detecting and reconstructing the e-mail address. The "secret" is just the fact that "at" is used to stand for "@", etc. Once the secret is known, the algorithm is trivial. In the image case, there is no secret. Nobody knows how to program a computer to read as well as person can -- not to mention, to be able to distinguish a picture containing letters from a picture of anything else. (And when they can, they'll probably be intelligent enough to defeat any other privacy technique anyway.) Serious research work would have to be done to solve the problem, and that's many years away. > > Just to give you an idea of what tricks are possible: a GIF can > > contain many different colour table entries that map to almost the > > same colour; the background can be patterned; the text can be > > distorted or blurred; the text can be drawn shadowed or embossed; > > And I'll bet in most of those situations, you just made your web site > none-ADA compliant. Which means it's a no-go for a lot of sites where > accessibility is necessary. Actually, now that I think about it, the simple > use of the graphic iwthout an acceptable ALT tag (which defeats the purpose > of the graphic) makes this non-compliant with ADA for sight-limited people > who use reader apps. That argument is a red herring. A site with images for the e-mail addresses (and ALT tags that did not reveal e-mail addresses) would certainly be no less accessible than one that omitted the e-mail addresses altogether. -- ?!ng "You should either succeed gloriously or fail miserably. Just getting by is the worst thing you can do." -- Larry Smith From noreply@sourceforge.net Tue Jul 30 12:23:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jul 2002 04:23:07 -0700 Subject: [Mailman-Developers] [ mailman-Patches-444879 ] Archive indexer control to improve index Message-ID: Patches item #444879, was opened at 2001-07-26 18:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444879&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Barrett (ppsys) Assigned to: Nobody/Anonymous (nobody) Summary: Archive indexer control to improve index Initial Comment: This patch is applicable to Mailman 2.0.6 release and supercedes ealier patches 401669 and 402422. This patch should improve the quality of search results returned by search engines such as htdig (http://www.htdig.org) where the seach engine's index builder responds to strings embedded in the html pages that are the subject of the indexing. The changes in this patch: 1. allow strings for enabling and disabling indexing to be defined in mm_cfg.py. 2. embeds those strings in the pages generated as the html version of a list's archive. By default nothing in the html changes. To get the desired effect, you must define ARCHIVE_INDEXING_ENABLE and ARCHIVE_INDEXING_DISABLE in mm_cfg.py You probably want to run this patch as follows: cd patch -p1 < See also the associated patch for integrating the htdig search software with mailman's internal archiver ouput. ---------------------------------------------------------------------- >Comment By: Richard Barrett (ppsys) Date: 2002-07-30 11:23 Message: Logged In: YES user_id=75166 indexing-2.0.13-0.1.patch is purely cosmetic to get no mumble application to MM 2.0.13 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-25 14:11 Message: Logged In: YES user_id=75166 indexing-2.0.11-0.1.patch should apply without problems to MM 2.0.12 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-05-23 09:50 Message: Logged In: YES user_id=75166 indexing-2.0.11-0.1.patch is a revised version of the patch that is compatible with MM 2.0.11 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-19 10:53 Message: Logged In: YES user_id=75166 indexing-2.0.9-0.1.patch should apply without problems to MM 2.0.10 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-08 17:43 Message: Logged In: YES user_id=75166 indexing-2.0.9-0.1.patch is a revised version of the patch that is compatible with MM 2.0.9 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-03-06 16:14 Message: Logged In: YES user_id=75166 indexing-2.1cvs-20020306.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 12:30 GMT 6 Mar 2002. Corrects problem noted or 5 Mar 2002 by nobody ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-03-05 21:41 Message: Logged In: NO When applying this patch I get an error with Hunk 1 and Defaults.py is not updated. This happens with the a clean download of the latest cvs installation (5 Mar 2002). Any ideas what the problem is? ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-17 16:53 Message: Logged In: YES user_id=75166 indexing-2.1cvs-20011217.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 11:50 GMT 17 Dec 2001 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-13 16:48 Message: Logged In: YES user_id=75166 indexing-2.1a3-0.1.patch is a revised version of the patch that is compatible with the code published in mailman-2.1a3.tgz on sourceforge. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 11:07 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.8 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-27 12:03 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.7 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444879&group_id=103 From noreply@sourceforge.net Tue Jul 30 12:25:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 30 Jul 2002 04:25:14 -0700 Subject: [Mailman-Developers] [ mailman-Patches-444884 ] Integration of Mailman & htdig for archi Message-ID: Patches item #444884, was opened at 2001-07-26 18:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444884&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Barrett (ppsys) Assigned to: Nobody/Anonymous (nobody) Summary: Integration of Mailman & htdig for archi Initial Comment: This patch is applicable to Mailman 2.0.6 release that has had search enhancement patch 444879 patch installed - if your Defaults.py has the ARCHIVE_INDEXING_ENABLE and ARCHIVE_INDEXING_DISABLE in it then you've got that patch. It replaces earlier patches 401670 and 402423 and is mainly to correct some problems arising from fixes introduced into Mailman by bug fix releases since the 402423 patch. This patch integrates htdig with Mailman and provides: 1. per list search facility with a search form on the list's TOC page. 2. maintenance of privacy of private archives which requires the user to establish their credentials via the normal private archive access before any access via htdig is allowed. 3. a common base URL for both public and private archive access via htsearch results so that htdig indices are unaffected by changingan archive from private to public and vice versa. All access to archives via htdig is controlled by a new wrapped cgi- bin script called htdig.py. 4. a new cron activated script and extra crontab entry which runs htdig regularly to maintain the per list search indices. 5. automatic creation, deletion and maintenance of htdig configuration files and such. Beyond installing htdig and telling Mailman where it is via mm_cfg you do not have to do any other setup. Well not quite you do have to set up a single per installation symlink to allow htdig to find the automatically generated per list htdig configuration files. You probably want to run this patch as follows: cd patch -p1 < ---------------------------------------------------------------------- >Comment By: Richard Barrett (ppsys) Date: 2002-07-30 11:25 Message: Logged In: YES user_id=75166 htdig-2.0.13-0.1.patch is purely cosmetic to get no mumble application to MM 2.0.13 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-25 15:07 Message: Logged In: YES user_id=75166 Do not use htdig-2.0.12-0.1.patch there is an error in it. Use htdig-2.0.12-0.2.patch instead ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-25 14:10 Message: Logged In: YES user_id=75166 htdig-2.0.12-0.1.patch is a revised version of the patch that applies without complaint to MM 2.0.12. It also add a facility for adding site wide htdig configuration attributes to all list specific htdig configuration files. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-05-23 09:59 Message: Logged In: YES user_id=75166 htdig-2.0.11-0.1.patch is a revised version of the patch that is compatible with MM 2.0.11 This version removes an incompatibility with Python 2.2 which caused warning messages to be generated when any of the family cron/nightly_htdig scripts were run. Some guidance on file access permissions for some htdig database files needed by rundig have been added to installation notes. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-19 10:59 Message: Logged In: YES user_id=75166 htdig-2.0.10-0.1.patch is a revised version of the patch that is compatible with MM 2.0.10 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-08 17:46 Message: Logged In: YES user_id=75166 htdig-2.0.9-0.1.patch is a revised version of the patch that is compatible with MM 2.0.9 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-03-06 16:22 Message: Logged In: YES user_id=75166 htdig-2.1cvs-20020306.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 12:30 GMT 6 Mar 2002 Known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-17 16:56 Message: Logged In: YES user_id=75166 htdig-2.1cvs-20011217.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 11:50 GMT 17 Dec 2001 The only known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-13 16:58 Message: Logged In: YES user_id=75166 htdig-2.1a3-0.1.patch is a revised version of the patch that is compatible with the code published in mailman-2.1a3.tgz on sourceforge. The only known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 17:33 Message: Logged In: YES user_id=75166 The htdig-2.0.8-0.1.patch version of the patch resolves a problem that can arise with htdig indexing if the web_page_url for a list uses other than the http addressing (some folks want to use https). While specified as for MM 2.0.8 the revised patch should work OK with 2.0.7, 2.0.6 and probably back as far as 2.0.3. If you do not have the requirement for using other than http addressing in you lists web_page_urls it probably isn't worth the trouble of upgrading to this patch level. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 11:08 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.8 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-27 12:00 Message: Logged In: YES user_id=75166 This patch should also apply without problems to Mm 2.0.7 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-09 11:54 Message: Logged In: YES user_id=75166 The htdig-2.0.6-03.patch version of the patch makes some previously hard-coded things configurable and enhances the capability to run the htdig searches and indexing on a different machine to the one delivering Mailman and Mailman's web UI. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444884&group_id=103 From barry@python.org Tue Jul 30 12:53:33 2002 From: barry@python.org (Barry A. Warsaw) Date: Tue, 30 Jul 2002 07:53:33 -0400 Subject: [Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use) References: <21784.1027735722@kanga.nu> <9508.1027922570@kanga.nu> <13773.1027963334@kanga.nu> <15685.53703.378405.962583@anthem.wooz.org> <15685.57281.971918.783688@anthem.wooz.org> <20632.1028013555@kanga.nu> Message-ID: <15686.32317.70430.914385@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: JCL> Given your prior comments and a brief review on this end of JCL> the relevant effort required: JCL> Have we now spent more time and effort on discussing this JCL> than would have been required to just do it? Yes, but I would have done it wrong. :) -Barry From barry@python.org Tue Jul 30 13:06:24 2002 From: barry@python.org (Barry A. Warsaw) Date: Tue, 30 Jul 2002 08:06:24 -0400 Subject: [Mailman-Developers] Off topic: a cautionary tale. References: Message-ID: <15686.33088.691332.558499@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> You get the picture. His search engine got into his database CVR> and deleted all of his data, because while it wasn't working, CVR> it COULD spider. And it got into an area it shouldn't have CVR> gotten into, even though it wasn't linked on the web site. Ouch. CVR> Happy hacking... But be careful out there. Thanks Sgt Esterhaus! :) -Barry From Dale@Newfield.org Tue Jul 30 13:34:50 2002 From: Dale@Newfield.org (Dale Newfield) Date: Tue, 30 Jul 2002 08:34:50 -0400 (EDT) Subject: [Mailman-Developers] Off topic: a cautionary tale. In-Reply-To: Message-ID: On Tue, 30 Jul 2002, Chuq Von Rospach wrote: > What got in was -- htDig, the search engine. Which happily follows all > links, including, if you let it spider phpMyAdmin, the "delete this > database" links. Including the database holding all of the MySQL > configuration and account info. Which causes MySQL to die. Which... I've thought for a while that phpMyAdmin was making a mistake with GET links for all those actions--they should be POST buttons, and spiders would not be able to do this. -Dale From chuqui@plaidworks.com Tue Jul 30 15:27:27 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 30 Jul 2002 07:27:27 -0700 Subject: [Mailman-Developers] Re: Opening up a few can o' worms here... In-Reply-To: Message-ID: On 7/30/02 3:41 AM, "Ka-Ping Yee" wrote: >> get 50% of your addresses or 5 passes to get 80%. They still win. > > I think they'd hardly be able to get any. Have you really thought about > how hard this would be? Why would they bother to invest the enormous > development effort to make this work for the one or two addresses they > *might* get, along with a large number of misread addresses? Yes, I have. Because I've seen how the spammers have moved up the technology curve when it suited their purposes. You're depending on not being "the low hanging fruit", so to speak. That's the philosophy behind "the club" for preventing car thefts. That philosophy works only as long as your data isn't valuable enough to be worth the extra effort. Once it does, you suddenly have a protection system that isn't working, but you've created a false sense of security because you think it works. That's worse than having no system, then, because you've stopped being worried about it. > In the image case, there is no secret. Nobody knows how to program a > computer to read as well as person can Have you seen what the off the shelf OCR systems like OmniPage do these days? >> And I'll bet in most of those situations, you just made your web site >> none-ADA compliant. Which means it's a no-go for a lot of sites where >> accessibility is necessary. > That argument is a red herring. Not for sites requiring ADA compliance, it's not. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ He doesn't have ulcers, but he's a carrier. From Nigel.Metheringham@dev.InTechnology.co.uk Tue Jul 30 15:43:52 2002 From: Nigel.Metheringham@dev.InTechnology.co.uk (Nigel Metheringham) Date: 30 Jul 2002 15:43:52 +0100 Subject: [Mailman-Developers] Cute TMDA use In-Reply-To: <3D4655E2.74D82F1E@mail.dcu.ie> References: <3D4655E2.74D82F1E@mail.dcu.ie> Message-ID: <1028040233.23063.111.camel@gaspode.localnet> An additional thing that would make me very much in favour of TDMA would be the possibility of adding a message to the confirmation stating that by posting to this list they are putting their messages into public archives. If they confirm the message then they have given permission for archiving. That would mean that all posts to the list are either from subscribers (who got the information about archiving at time of subscription), or those that have confirmed their willingness to be archived. This could be useful in a legal sense for me... since some idiots wish to rewrite history and I need to make sure that everyone posting did agree with the policy. My alternative is to just reject all held postings out of hand. Nigel. -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From laurence@digitalpulp.com Tue Jul 30 15:57:36 2002 From: laurence@digitalpulp.com (Laurence Berland) Date: Tue, 30 Jul 2002 10:57:36 -0400 Subject: [Mailman-Developers] Patch to add general regex filtering module, hooks to archive Message-ID: <200207301057.36875.laurence@digitalpulp.com> All, =09I've written and now tested a new Handler module, Filter.py, and I've = added=20 the various hooks it needs to filter on messages before they are archived= =2E =20 There are about 70billion different uses for this sort of thing, but the = one=20 I'm after is replacing a string (say :1:) with an image tag (say ). My two questions are thus: 1. Is there a way to turn off the conversion of < and > to %lt; etc in t= he=20 archive for a specific list? 2. Where should I submit my patches? They're against a cvs checkout fro= m=20 yesterday afternoon, so likely will patch completely cleanly into the cod= e. Laurence From barry@python.org Tue Jul 30 16:18:42 2002 From: barry@python.org (Barry A. Warsaw) Date: Tue, 30 Jul 2002 11:18:42 -0400 Subject: [Mailman-Developers] Off topic: a cautionary tale. References: Message-ID: <15686.44626.345391.819022@anthem.wooz.org> >>>>> "DN" == Dale Newfield writes: DN> On Tue, 30 Jul 2002, Chuq Von Rospach wrote: >> What got in was -- htDig, the search engine. Which happily >> follows all links, including, if you let it spider phpMyAdmin, >> the "delete this database" links. Including the database >> holding all of the MySQL configuration and account info. Which >> causes MySQL to die. Which... DN> I've thought for a while that phpMyAdmin was making a mistake DN> with GET links for all those actions--they should be POST DN> buttons, and spiders would not be able to do this. We had this discussion a while back w.r.t. Mailman's web confirmation pages. It was pointed out (forcefully ;) that GETs shouldn't have side effects, and should be reproducible, so the web confirmations were turned into POSTs. Sounds like phpMyAdmin is violating the conventions. As an added precaution, for non-undoable actions like deleting a list, Mailman requires the list admin password, even though it knows you're authenticated. -Barry From ping@zesty.ca Tue Jul 30 18:01:08 2002 From: ping@zesty.ca (Ka-Ping Yee) Date: Tue, 30 Jul 2002 10:01:08 -0700 (PDT) Subject: [Mailman-Developers] Re: Opening up a few can o' worms here... In-Reply-To: Message-ID: On Tue, 30 Jul 2002, Chuq Von Rospach wrote: > Yes, I have. Because I've seen how the spammers have moved up the technology > curve when it suited their purposes. Keep in mind that you are talking about technology that doesn't exist yet. It's trivial to write harvesting software with more features for, say, processing HTML -- but in the case of OCR, there's no curve to move up. > You're depending on not being "the low hanging fruit", so to speak. To some extent, yes, if you consider putting the fruit on an airplane and flying over a medieval village to be "low-hanging fruit". Sure, they will get to that fruit before they reach the fruit on the moon. But if we really get to the point where everyone has to use images to communicate instead of text, i think that will mean SMTP is obsolete. > > In the image case, there is no secret. Nobody knows how to program a > > computer to read as well as person can > > Have you seen what the off the shelf OCR systems like OmniPage do these > days? Yes -- the performance is awful. And that's on ordinary printed text that's supposed to be readable, not on text that has been intentionally obfuscated. > >> And I'll bet in most of those situations, you just made your web site > >> none-ADA compliant. Which means it's a no-go for a lot of sites where > >> accessibility is necessary. > > > That argument is a red herring. > > Not for sites requiring ADA compliance, it's not. I'm going to stop here, since it is clear that you're not reading what you're responding to. Please go back and look at what i wrote. And then please describe how your proposed alternative will display e-mail addresses in a form readable by screen readers for the blind and not by spammers. -- ?!ng From chuqui@plaidworks.com Tue Jul 30 17:57:47 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 30 Jul 2002 09:57:47 -0700 Subject: [Mailman-Developers] Re: Opening up a few can o' worms here... In-Reply-To: <3D46C198.9090808@sun.com> Message-ID: On 7/30/02 9:40 AM, "Dan Mick" wrote: > Do you mean that the premise, > "the email address is either inaccessible or inaccessible just to > ADA folks" is not valid? No, I don't. Programmatically obfuscating an email address still makes that obfuscated email address available to a reader app for a sight-limited person. So at least he gets something that can be interpreted. If you put it in a graphic, since you can't (by definition) put readable content in the ALT tag, that person ends up with a big empty, which means it's no longer accessible. If that is, say, the email address of the admin of the list, that list is not ADA compliant because a site-limited person can't get to the data to manually deobfuscate it. (one could argue that obfuscating an admin address would be bad usability for novice users, but that's a different argument and not ADA oriented). But beyond that, this is really a side-argument to my main one, which is that this is really a fix of false security, since those graphics are only safe as long as it's not worth the time of the spammers to decode them. You can argue difficulty all you want -- I've seen what Omnipage is capable on macOS these days, and graphics aren't safe as soon as someone decides to go after them. And, unfortunately, some of the techniques Ka-Ping suggest to go after the OCR systems also fail ADA compliance because they're going to totally hose over folks like the colorblind. And, frankly, if you play a bit with photoshop filters and photo-retouching techniques, you'll find very few of those techniques will survive even trivial attempts to pull out the information. I'm categorically against "fixes" that assume "they'll go after someone easier", because they lull you into false feelings of security, and then when they DO decide to target you, you aren't really secure, and you aren't really looking for the attack. Either fix it right, or don't bother fixing it, IMHO. And graphics fail too many tests for me to take them seriously. (this is one reason why, for instance, we are reinventing our archive system to remove the passwords we're currently using to keep the bots out. Because that's a system that doesn't really solve the problem, any more than a "do not enter" sign on an unlocked door stops a burglar. It only stops stupid burglars.) -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Very funny, Scotty. Now beam my clothes down here, will you? From claw@kanga.nu Tue Jul 30 18:05:41 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 30 Jul 2002 10:05:41 -0700 Subject: [Mailman-Developers] Off topic: a cautionary tale. In-Reply-To: Message from Dale Newfield of "Tue, 30 Jul 2002 08:34:50 EDT." References: Message-ID: <24654.1028048741@kanga.nu> On Tue, 30 Jul 2002 08:34:50 -0400 (EDT) Dale Newfield wrote: > I've thought for a while that phpMyAdmin was making a mistake with GET > links for all those actions--they should be POST buttons, and spiders > would not be able to do this. It is making a mistake. W3C specs state that only POSTs may have side effects, not GETs. -- 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 claw@kanga.nu Tue Jul 30 18:09:30 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 30 Jul 2002 10:09:30 -0700 Subject: [Mailman-Developers] Cute TMDA use In-Reply-To: Message from Nigel Metheringham of "30 Jul 2002 15:43:52 BST." <1028040233.23063.111.camel@gaspode.localnet> References: <3D4655E2.74D82F1E@mail.dcu.ie> <1028040233.23063.111.camel@gaspode.localnet> Message-ID: <24692.1028048970@kanga.nu> On 30 Jul 2002 15:43:52 +0100 Nigel Metheringham wrote: > An additional thing that would make me very much in favour of TDMA > would be the possibility of adding a message to the confirmation > stating that by posting to this list they are putting their messages > into public archives. If they confirm the message then they have > given permission for archiving. TMDA handles that by making all the confirmation, request etc messages template based, with the template directory having both a default and a CLI switch (eg for per list customisation in our case). > That would mean that all posts to the list are either from subscribers > (who got the information about archiving at time of subscription), or > those that have confirmed their willingness to be archived. Excellent point. I like it. Note however that that implies that subscribers who post have to verify thru TMDA. -- 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 claw@kanga.nu Tue Jul 30 18:14:02 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 30 Jul 2002 10:14:02 -0700 Subject: [Mailman-Developers] Re: Opening up a few can o' worms here... In-Reply-To: Message from Chuq Von Rospach of "Tue, 30 Jul 2002 09:57:47 PDT." References: Message-ID: <24770.1028049242@kanga.nu> On Tue, 30 Jul 2002 09:57:47 -0700 Chuq Von Rospach wrote: > (this is one reason why, for instance, we are reinventing our archive > system to remove the passwords we're currently using to keep the bots > out. Because that's a system that doesn't really solve the problem, > any more than a "do not enter" sign on an unlocked door stops a > burglar. It only stops stupid burglars.) Building the archives (even if not the list) with dated or sender addresses TMDA-style starts seeming quite attractive. -- 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@plaidworks.com Tue Jul 30 18:13:07 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 30 Jul 2002 10:13:07 -0700 Subject: [Mailman-Developers] Re: Opening up a few can o' worms here... In-Reply-To: Message-ID: On 7/30/02 10:01 AM, "Ka-Ping Yee" wrote: >>> That argument is a red herring. >> >> Not for sites requiring ADA compliance, it's not. > > I'm going to stop here, since it is clear that you're not reading what > you're responding to. Please go back and look at what i wrote. I did. But I'll stop, too. Obviously, you don't want to hear what I'm saying, either. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Very funny, Scotty. Now beam my clothes down here, will you? From barry@python.org Tue Jul 30 18:13:54 2002 From: barry@python.org (Barry A. Warsaw) Date: Tue, 30 Jul 2002 13:13:54 -0400 Subject: [Mailman-Developers] Cute TMDA use References: <3D4655E2.74D82F1E@mail.dcu.ie> <1028040233.23063.111.camel@gaspode.localnet> <24692.1028048970@kanga.nu> Message-ID: <15686.51538.28466.776823@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: >> That would mean that all posts to the list are either from >> subscribers (who got the information about archiving at time of >> subscription), or those that have confirmed their willingness >> to be archived. JCL> Excellent point. I like it. Me too. JCL> Note however that that implies that subscribers who post have JCL> to verify thru TMDA. Not necessarily. Mailman's replybot can be set up to provide that information to them during the confirmation handshake. BTW, cooler heads have prevailed. I'm not going to build this into MM2.1, although I have added some notes to the TODO file. -Barry From claw@kanga.nu Tue Jul 30 18:20:22 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 30 Jul 2002 10:20:22 -0700 Subject: [Mailman-Developers] Cute TMDA use In-Reply-To: Message from barry@python.org (Barry A. Warsaw) of "Tue, 30 Jul 2002 13:13:54 EDT." <15686.51538.28466.776823@anthem.wooz.org> References: <3D4655E2.74D82F1E@mail.dcu.ie> <1028040233.23063.111.camel@gaspode.localnet> <24692.1028048970@kanga.nu> <15686.51538.28466.776823@anthem.wooz.org> Message-ID: <24907.1028049622@kanga.nu> On Tue, 30 Jul 2002 13:13:54 -0400 Barry A Warsaw wrote: >>>>>> "JCL" == J C Lawrence writes: >>> That would mean that all posts to the list are either from >>> subscribers (who got the information about archiving at time of >>> subscription), or those that have confirmed their willingness to be >>> archived. JCL> Excellent point. I like it. > Me too. JCL> Note however that that implies that subscribers who post have to JCL> verify thru TMDA. > Not necessarily. Mailman's replybot can be set up to provide that > information to them during the confirmation handshake. Yes, but the point (I think) is that Nathan wants something explicitly linked against posting versus subscribing or other generic list activity. "You are posting to the list and you've not done that before. Please realise that by posting your message will be archived for posterity and the purposes of blackmail and public embarrassment and there won't be a damn thing you can do about it. Do you really want to post to this list?" Nathan has already stated he's interested in some of the legal CYA, and for that (I expect) he needs an explicit decision at the time of first post, not first subscribe. Note; With an integrated TMDA setup such as I'm doing (versus TMDA-like features in Mailman) this is fairly simple to accomplish. You just don't point TMDA at your Mailman configs as a source of valid email addresses. > BTW, cooler heads have prevailed. I'm not going to build this into > MM2.1, although I have added some notes to the TODO file. Ahh. Damn. -- 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 Dan.Mick@sun.com Tue Jul 30 17:38:30 2002 From: Dan.Mick@sun.com (Dan Mick) Date: Tue, 30 Jul 2002 09:38:30 -0700 Subject: [Mailman-Developers] Cute TMDA use References: <3D4655E2.74D82F1E@mail.dcu.ie> Message-ID: <3D46C106.1010704@sun.com> > The above would be great!! We currently have a problem with students > (university environment) sending "spam" to hundreds of lists so they can > find a room mate!! ...And note that this is an argument for list-specific (i.e. non-global) whitelists, as "just because you can post to the alt.magic.i-have-no-life list doesn't give you the right to post to wedding-planners, just because they happen to share disk space on the same host cluster". From Dan.Mick@sun.com Tue Jul 30 17:40:56 2002 From: Dan.Mick@sun.com (Dan Mick) Date: Tue, 30 Jul 2002 09:40:56 -0700 Subject: [Mailman-Developers] Re: Opening up a few can o' worms here... References: Message-ID: <3D46C198.9090808@sun.com> Chuq Von Rospach wrote: >>That argument is a red herring. > > > Not for sites requiring ADA compliance, it's not. You didn't answer the argument, Chuq, which was that "it doesn't matter how you make the email address inaccessible if it's going to end up inaccessible". Do you mean that the premise, "the email address is either inaccessible or inaccessible just to ADA folks" is not valid? From Dan.Mick@sun.com Tue Jul 30 18:10:28 2002 From: Dan.Mick@sun.com (Dan Mick) Date: Tue, 30 Jul 2002 10:10:28 -0700 Subject: [Mailman-Developers] Re: Opening up a few can o' worms here... References: Message-ID: <3D46C884.80502@sun.com> Chuq Von Rospach wrote: > On 7/30/02 9:40 AM, "Dan Mick" wrote: > > >>Do you mean that the premise, >>"the email address is either inaccessible or inaccessible just to >>ADA folks" is not valid? > > > No, I don't. Programmatically obfuscating an email address still makes that > obfuscated email address available to a reader app for a sight-limited > person. So at least he gets something that can be interpreted. If you put it > in a graphic, since you can't (by definition) put readable content in the > ALT tag, that person ends up with a big empty, which means it's no longer > accessible. That sounds like a "yes the premise is invalid", not a "no". Ka-Ping said "if you make the address inaccessible to all, that's worse than making it inaccessible only to ADA folks, so the latter is a net win." You're apparently assuming that there is no acceptable solution that will make the address inaccessible to all, which is a reasonable assumption, but not what Ka-Ping was saying. From Donal.Hunt2@mail.dcu.ie Tue Jul 30 18:20:53 2002 From: Donal.Hunt2@mail.dcu.ie (Donal Hunt) Date: Tue, 30 Jul 2002 18:20:53 +0100 Subject: [Mailman-Developers] Cute TMDA use Message-ID: <3D46CAF5.5EB12E71@mail.dcu.ie> Dan Mick wrote: > > > The above would be great!! We currently have a problem with students > > (university environment) sending "spam" to hundreds of lists so they can > > find a room mate!! > > ...And note that this is an argument for list-specific (i.e. non-global) > whitelists, as "just because you can post to the alt.magic.i-have-no-life > list doesn't give you the right to post to wedding-planners, just because > they happen to share disk space on the same host cluster". Most definately. Donal DCU From chuqui@plaidworks.com Tue Jul 30 18:24:25 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 30 Jul 2002 10:24:25 -0700 Subject: [Mailman-Developers] Re: Opening up a few can o' worms here... In-Reply-To: <3D46C884.80502@sun.com> Message-ID: On 7/30/02 10:10 AM, "Dan Mick" wrote: > That sounds like a "yes the premise is invalid", not a "no". Thank you for explaining to me what I said, because otherwise, I wouldn't have known what it was I was saying. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ IMHO: Jargon. Acronym for In My Humble Opinion. Used to flag as an opinion something that is clearly from context an opinion to everyone except the mentally dense. Opinions flagged by IMHO are actually rarely humble. IMHO. (source: third unabridged dictionary of chuqui-isms). From barry@python.org Tue Jul 30 18:26:13 2002 From: barry@python.org (Barry A. Warsaw) Date: Tue, 30 Jul 2002 13:26:13 -0400 Subject: [Mailman-Developers] Cute TMDA use References: <3D4655E2.74D82F1E@mail.dcu.ie> <1028040233.23063.111.camel@gaspode.localnet> <24692.1028048970@kanga.nu> <15686.51538.28466.776823@anthem.wooz.org> <24907.1028049622@kanga.nu> Message-ID: <15686.52277.363043.899578@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: JCL> Nathan has already stated he's interested in some of the JCL> legal CYA, and for that (I expect) he needs an explicit JCL> decision at the time of first post, not first subscribe. Ah. You know, Mailman is /almost/ there. You can set up a replybot on receiving a message to the posting address. That plus quarantined moderation nearly gets you there. The one bit that you'd need to add is the actual explicit confirmation step. JCL> Note; With an integrated TMDA setup such as I'm doing (versus JCL> TMDA-like features in Mailman) this is fairly simple to JCL> accomplish. You just don't point TMDA at your Mailman JCL> configs as a source of valid email addresses. >> BTW, cooler heads have prevailed. I'm not going to build this >> into MM2.1, although I have added some notes to the TODO file. JCL> Ahh. Damn. I know, I know. I'd really like to see how the TMDA stuff pans out as more people use it. I think rather than run headlong into adding a feature at the last minute (so to speak), we can take a principled look at how to improve and borrow things for the next Mailman release. -Barry From Dan.Mick@sun.com Tue Jul 30 18:22:33 2002 From: Dan.Mick@sun.com (Dan Mick) Date: Tue, 30 Jul 2002 10:22:33 -0700 Subject: [Mailman-Developers] Re: Opening up a few can o' worms here... References: Message-ID: <3D46CB59.7090706@sun.com> Chuq Von Rospach wrote: > On 7/30/02 10:10 AM, "Dan Mick" wrote: > > >>That sounds like a "yes the premise is invalid", not a "no". > > > Thank you for explaining to me what I said, because otherwise, I wouldn't > have known what it was I was saying. Oh, for Christ's sake, Chuq, isn't someone allowed to ask you to clarify, because they're just Far Stupider than You? Damn. I was trying to add clarification rather than snottiness, and you just refuse. From barry@python.org Tue Jul 30 18:30:48 2002 From: barry@python.org (Barry A. Warsaw) Date: Tue, 30 Jul 2002 13:30:48 -0400 Subject: [Mailman-Developers] Re: Opening up a few can o' worms here... References: <3D46CB59.7090706@sun.com> Message-ID: <15686.52552.89531.761863@anthem.wooz.org> Hey maybe I'll get a chance to test out this emergency moderation feature all the kids are raving about these days! :) -Barry From claw@kanga.nu Tue Jul 30 18:35:31 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 30 Jul 2002 10:35:31 -0700 Subject: [Mailman-Developers] Cute TMDA use In-Reply-To: Message from barry@python.org (Barry A. Warsaw) of "Tue, 30 Jul 2002 13:26:13 EDT." <15686.52277.363043.899578@anthem.wooz.org> References: <3D4655E2.74D82F1E@mail.dcu.ie> <1028040233.23063.111.camel@gaspode.localnet> <24692.1028048970@kanga.nu> <15686.51538.28466.776823@anthem.wooz.org> <24907.1028049622@kanga.nu> <15686.52277.363043.899578@anthem.wooz.org> Message-ID: <25110.1028050531@kanga.nu> On Tue, 30 Jul 2002 13:26:13 -0400 Barry A Warsaw wrote: > I know, I know. I'd really like to see how the TMDA stuff pans out as > more people use it. I think rather than run headlong into adding a > feature at the last minute (so to speak), we can take a principled > look at how to improve and borrow things for the next Mailman release. Fair dinkum. Good reasoning. I'll be rolling by TMDA front end to all the lists at Kanga.Nu later today (need some more testing first). I'll report on -developers once its gold, probably along with a test/temp list for -developers people to try playing with the system. -- 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 ping@zesty.ca Tue Jul 30 18:36:35 2002 From: ping@zesty.ca (Ka-Ping Yee) Date: Tue, 30 Jul 2002 10:36:35 -0700 (PDT) Subject: [Mailman-Developers] Re: Opening up a few can o' worms here... In-Reply-To: <15686.52552.89531.761863@anthem.wooz.org> Message-ID: On Tue, 30 Jul 2002, Barry A. Warsaw wrote: > > Hey maybe I'll get a chance to test out this emergency moderation > feature all the kids are raving about these days! :) Sorry, Barry. You know that once a Canadian joins the conversation, all hope of propriety is lost. :) -- ?!ng From chuqui@plaidworks.com Tue Jul 30 18:22:39 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 30 Jul 2002 10:22:39 -0700 Subject: [Mailman-Developers] Re: Opening up a few can o' worms here... In-Reply-To: <24770.1028049242@kanga.nu> Message-ID: On 7/30/02 10:14 AM, "J C Lawrence" wrote: > Building the archives (even if not the list) with dated or sender > addresses TMDA-style starts seeming quite attractive. Actually, we're putting everything behind a CGI that'll enforce our policies. That way, if the policies change, only the CGI has to be modified, not the archives. And we don't have to modify the archives -- which is problematic if you take stuff out that later you decide ought to be there. An unmodified archive is a lot easier to deal with. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Yes, I am an agent of Satan, but my duties are largely ceremonial. From JasonR.Mastaler Tue Jul 30 18:46:07 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Tue, 30 Jul 2002 11:46:07 -0600 Subject: [Mailman-Developers] Re: Cute TMDA use References: <3D4655E2.74D82F1E@mail.dcu.ie> <3D46C106.1010704@sun.com> Message-ID: Dan Mick writes: > ...And note that this is an argument for list-specific > (i.e. non-global) whitelists Which is another argument for not building this into MM until it can be properly addressed. With TMDA, the list admin can choose whether or not to use a per-list whitelist or a global whitelist, so it's not an issue. -- (http://tmda.net/) From JasonR.Mastaler Tue Jul 30 18:47:07 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Tue, 30 Jul 2002 11:47:07 -0600 Subject: [Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use) References: <200207300306.g6U36mOl011491@utopia.West.Sun.COM> <20791.1028014177@kanga.nu> Message-ID: J C Lawrence writes: > Note: SF is likely going to have severe performance problems with > the current flatfile list implementation. Odds are that they're > going to want a persistent SQL-backed implementation due to their > size. What flatfile list implementation are you referring to? -- (http://tmda.net/) From claw@kanga.nu Tue Jul 30 18:53:22 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 30 Jul 2002 10:53:22 -0700 Subject: [Mailman-Developers] Re: Opening up a few can o' worms here... In-Reply-To: Message from Chuq Von Rospach of "Tue, 30 Jul 2002 10:22:39 PDT." References: Message-ID: <25379.1028051602@kanga.nu> On Tue, 30 Jul 2002 10:22:39 -0700 Chuq Von Rospach wrote: > On 7/30/02 10:14 AM, "J C Lawrence" wrote: >> Building the archives (even if not the list) with dated or sender >> addresses TMDA-style starts seeming quite attractive. > Actually, we're putting everything behind a CGI that'll enforce our > policies. That way, if the policies change, only the CGI has to be > modified, not the archives. And we don't have to modify the archives > -- which is problematic if you take stuff out that later you decide > ought to be there. An unmodified archive is a lot easier to deal > with. Yeah, I get the same end by a MVC abstraction in my (currently) PHP template processing code. The raw PHP file generated by MHonArc is, well, raw. The external globally shared code that does the actual render to HTML etc can re-wrap/re-present etc as desired. (Which is really just making a false distinction between PHP pages using shared code and a CGI). -- 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 claw@kanga.nu Tue Jul 30 18:58:46 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 30 Jul 2002 10:58:46 -0700 Subject: [Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use) In-Reply-To: Message from Jason R.Mastaler of "Tue, 30 Jul 2002 11:47:07 MDT." References: <200207300306.g6U36mOl011491@utopia.West.Sun.COM> <20791.1028014177@kanga.nu> Message-ID: <25487.1028051926@kanga.nu> On Tue, 30 Jul 2002 11:47:07 -0600 Jason R Mastaler wrote: > J C Lawrence writes: >> Note: SF is likely going to have severe performance problems with the >> current flatfile list implementation. Odds are that they're going to >> want a persistent SQL-backed implementation due to their size. > What flatfile list implementation are you referring to? I failed to noticed the cdb/dbm/etc list code. Ooops. -- 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 barry@python.org Tue Jul 30 19:02:04 2002 From: barry@python.org (Barry A. Warsaw) Date: Tue, 30 Jul 2002 14:02:04 -0400 Subject: [Mailman-Developers] Cute TMDA use References: <3D4655E2.74D82F1E@mail.dcu.ie> <1028040233.23063.111.camel@gaspode.localnet> <24692.1028048970@kanga.nu> <15686.51538.28466.776823@anthem.wooz.org> <24907.1028049622@kanga.nu> <15686.52277.363043.899578@anthem.wooz.org> <25110.1028050531@kanga.nu> Message-ID: <15686.54428.61922.670691@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: JCL> Fair dinkum. Good reasoning. I'll be rolling by TMDA front JCL> end to all the lists at Kanga.Nu later today (need some more JCL> testing first). I'll report on -developers once its gold, JCL> probably along with a test/temp list for -developers people JCL> to try playing with the system. Please feel free to contribute a Howto, FAQ entry or any other written docs on your set up. I'll add it to the distro where appropriate. It's cool stuff that others are definitely going to be interested in. -Barry From claw@kanga.nu Tue Jul 30 19:04:58 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 30 Jul 2002 11:04:58 -0700 Subject: [Mailman-Developers] Cute TMDA use In-Reply-To: Message from barry@python.org (Barry A. Warsaw) of "Tue, 30 Jul 2002 14:02:04 EDT." <15686.54428.61922.670691@anthem.wooz.org> References: <3D4655E2.74D82F1E@mail.dcu.ie> <1028040233.23063.111.camel@gaspode.localnet> <24692.1028048970@kanga.nu> <15686.51538.28466.776823@anthem.wooz.org> <24907.1028049622@kanga.nu> <15686.52277.363043.899578@anthem.wooz.org> <25110.1028050531@kanga.nu> <15686.54428.61922.670691@anthem.wooz.org> Message-ID: <25593.1028052298@kanga.nu> On Tue, 30 Jul 2002 14:02:04 -0400 Barry A Warsaw wrote: >>>>>> "JCL" == J C Lawrence writes: JCL> Fair dinkum. Good reasoning. I'll be rolling by TMDA front end to JCL> all the lists at Kanga.Nu later today (need some more testing JCL> first). I'll report on -developers once its gold, probably along JCL> with a test/temp list for -developers people to try playing with JCL> the system. > Please feel free to contribute a Howto, FAQ entry or any other written > docs on your set up. I'll add it to the distro where appropriate. > It's cool stuff that others are definitely going to be interested in. Absolutely. That's been the oft stated plan. -- 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 Dan.Mick@sun.com Tue Jul 30 19:03:58 2002 From: Dan.Mick@sun.com (Dan Mick) Date: Tue, 30 Jul 2002 11:03:58 -0700 Subject: [Mailman-Developers] Re: Cute TMDA use References: <3D4655E2.74D82F1E@mail.dcu.ie> <3D46C106.1010704@sun.com> Message-ID: <3D46D50E.5010607@sun.com> Jason R. Mastaler wrote: > Dan Mick writes: > > >>...And note that this is an argument for list-specific >>(i.e. non-global) whitelists > > > Which is another argument for not building this into MM until it can > be properly addressed. > > With TMDA, the list admin can choose whether or not to use a per-list > whitelist or a global whitelist, so it's not an issue. Yeah. It occurs to me that what we're exploring is "defenses against different sorts of unwanted email"; in one case, the classical spammer with a nonresponding address, "world-global" whitelisting makes sense; in the other, "casual user of one list broadcasting to many lists", global whitelist is not the best answer...but it's a different problem. Probably some combination of list-specific, server-global, and middle ground of "list-collection-shared" whitelists would address a lot of user's needs (so configurable is probably the right answer). I'd argue that the default "list-specific" is the right default, with sharing a tweakable option. Definitely makes me that much more anxious to go explore TMDA now, though (that, plus the fact that, as you predicted, Jason, SpamAssassin is running out of gas and letting more and more through). From barry@python.org Tue Jul 30 19:17:09 2002 From: barry@python.org (Barry A. Warsaw) Date: Tue, 30 Jul 2002 14:17:09 -0400 Subject: [Mailman-Developers] Cute TMDA use References: <3D4655E2.74D82F1E@mail.dcu.ie> <1028040233.23063.111.camel@gaspode.localnet> <24692.1028048970@kanga.nu> <15686.51538.28466.776823@anthem.wooz.org> <24907.1028049622@kanga.nu> <15686.52277.363043.899578@anthem.wooz.org> <25110.1028050531@kanga.nu> <15686.54428.61922.670691@anthem.wooz.org> <25593.1028052298@kanga.nu> Message-ID: <15686.55333.173743.450015@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: >> Please feel free to contribute a Howto, FAQ entry or any other >> written docs on your set up. I'll add it to the distro where >> appropriate. It's cool stuff that others are definitely going >> to be interested in. JCL> Absolutely. That's been the oft stated plan. Excellent. -Barry From JasonR.Mastaler Tue Jul 30 19:20:24 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Tue, 30 Jul 2002 12:20:24 -0600 Subject: [Mailman-Developers] Re: Cute TMDA use References: <3D4655E2.74D82F1E@mail.dcu.ie> <1028040233.23063.111.camel@gaspode.localnet> <24692.1028048970@kanga.nu> <15686.51538.28466.776823@anthem.wooz.org> <24907.1028049622@kanga.nu> <15686.52277.363043.899578@anthem.wooz.org> <25110.1028050531@kanga.nu> <15686.54428.61922.670691@anthem.wooz.org> Message-ID: barry@python.org (Barry A. Warsaw) writes: > Please feel free to contribute a Howto, FAQ entry or any other > written docs on your set up. I'll add it to the distro where > appropriate. Where do you think these docs should be maintained? In the Mailman, or TMDA tree? -- (http://tmda.net/) From laurence@digitalpulp.com Tue Jul 30 19:22:57 2002 From: laurence@digitalpulp.com (Laurence Berland) Date: Tue, 30 Jul 2002 14:22:57 -0400 Subject: [Mailman-Developers] Adding exception to html-stripping in the archive Message-ID: <200207301422.57526.laurence@digitalpulp.com> All, =09I posted this earlier, but it was sort of buried in an email about not= =20 necessarily related things. Here's what I'm trying to do: I've already written code that filters the messages on their way to the=20 archiver, substituting based on regular expressions. It does this in the= =20 Queue/ArchRunner.py file, in just about the last spot before the actual=20 archiver gets called. It can't go in the archiver, because it needs to b= e=20 able to read the mlist variable for configuration and such. I need to be= =20 able to use a regular expression to substitute in a snippet of html code.= =20 This could be used for several things, but my intention is to use it to a= dd=20 an img tag. Is there a way to configurably get around the html-sanitizin= g=20 done by the archiver in some non-kludge way? TIA, Laurence From JasonR.Mastaler Tue Jul 30 19:30:18 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Tue, 30 Jul 2002 12:30:18 -0600 Subject: [Mailman-Developers] Re: Cute TMDA use References: <3D4655E2.74D82F1E@mail.dcu.ie> <3D46C106.1010704@sun.com> <3D46D50E.5010607@sun.com> Message-ID: Dan Mick writes: > (that, plus the fact that, as you predicted, Jason, SpamAssassin is > running out of gas and letting more and more through). My personal stats these days are: ~900 attempted spams/month, down from ~1300 due to activating RBL (relays.ordb.org). I'm going on 8 weeks without actually receiving a single piece of that spam. During the past 12 months, only 6% of legitimate senders have been faced with a confirmation request (due to use of a comprehensive whitelist with auto-update + liberal use of 'dated' addresses). So, I've got my configuration pretty nailed down I think. :-) -- (http://tmda.net/) From barry@python.org Tue Jul 30 19:36:26 2002 From: barry@python.org (Barry A. Warsaw) Date: Tue, 30 Jul 2002 14:36:26 -0400 Subject: [Mailman-Developers] Re: Cute TMDA use References: <3D4655E2.74D82F1E@mail.dcu.ie> <1028040233.23063.111.camel@gaspode.localnet> <24692.1028048970@kanga.nu> <15686.51538.28466.776823@anthem.wooz.org> <24907.1028049622@kanga.nu> <15686.52277.363043.899578@anthem.wooz.org> <25110.1028050531@kanga.nu> <15686.54428.61922.670691@anthem.wooz.org> Message-ID: <15686.56490.56505.700259@anthem.wooz.org> >>>>> "JRM" == Jason R Mastaler writes: >> Please feel free to contribute a Howto, FAQ entry or any other >> written docs on your set up. I'll add it to the distro where >> appropriate. JRM> Where do you think these docs should be maintained? In the JRM> Mailman, or TMDA tree? Hmm, good question. Probably in both places, but with different audiences in mind. The Mailman docs should probably be geared towards "here's something really cool that you can do with a TMDA add-on". The TMDA docs probably want to go into more detail about how to integrate the two apps, including various ways you might want to configure TMDA to get it to work optimally with Mailman. But I'm open to other suggestions. -Barry From JasonR.Mastaler Tue Jul 30 19:48:06 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Tue, 30 Jul 2002 12:48:06 -0600 Subject: [Mailman-Developers] Re: Cute TMDA use References: <3D4655E2.74D82F1E@mail.dcu.ie> <1028040233.23063.111.camel@gaspode.localnet> <24692.1028048970@kanga.nu> <15686.51538.28466.776823@anthem.wooz.org> <24907.1028049622@kanga.nu> <15686.52277.363043.899578@anthem.wooz.org> <25110.1028050531@kanga.nu> <15686.54428.61922.670691@anthem.wooz.org> <15686.56490.56505.700259@anthem.wooz.org> Message-ID: barry@python.org (Barry A. Warsaw) writes: > The Mailman docs should probably be geared towards "here's something > really cool that you can do with a TMDA add-on". Right. Presenting a bunch of gory configuration details to a TMDA unaware audience isn't a very good idea I think. > The TMDA docs probably want to go into more detail about how to > integrate the two apps, including various ways you might want to > configure TMDA to get it to work optimally with Mailman. This is what I had in mind as well. I'll start a "Mailman HOWTO" for the TMDA docs which does this. Perhaps J C can add his info to this as well when finished. Then perhaps a couple more general entries for Mailman's FAQ Wizard which link to the above document can be written. -- (http://tmda.net/) From barry@python.org Tue Jul 30 19:54:05 2002 From: barry@python.org (Barry A. Warsaw) Date: Tue, 30 Jul 2002 14:54:05 -0400 Subject: [Mailman-Developers] Re: Cute TMDA use References: <3D4655E2.74D82F1E@mail.dcu.ie> <1028040233.23063.111.camel@gaspode.localnet> <24692.1028048970@kanga.nu> <15686.51538.28466.776823@anthem.wooz.org> <24907.1028049622@kanga.nu> <15686.52277.363043.899578@anthem.wooz.org> <25110.1028050531@kanga.nu> <15686.54428.61922.670691@anthem.wooz.org> <15686.56490.56505.700259@anthem.wooz.org> Message-ID: <15686.57549.772095.621064@anthem.wooz.org> >>>>> "JRM" == Jason R Mastaler writes: >> The Mailman docs should probably be geared towards "here's >> something really cool that you can do with a TMDA add-on". JRM> Right. Presenting a bunch of gory configuration details to a JRM> TMDA unaware audience isn't a very good idea I think. >> The TMDA docs probably want to go into more detail about how to >> integrate the two apps, including various ways you might want >> to configure TMDA to get it to work optimally with Mailman. JRM> This is what I had in mind as well. I'll start a "Mailman JRM> HOWTO" for the TMDA docs which does this. Perhaps J C can JRM> add his info to this as well when finished. JRM> Then perhaps a couple more general entries for Mailman's FAQ JRM> Wizard which link to the above document can be written. Beauty. -Barry From les@2pi.org Tue Jul 30 20:12:47 2002 From: les@2pi.org (Les Niles) Date: Tue, 30 Jul 2002 12:12:47 -0700 Subject: [Mailman-Developers] Almost OT: Re: Opening up a few can o' worms here... In-Reply-To: (message from Chuq Von Rospach on Tue, 30 Jul 2002 07:27:27 -0700) References: Message-ID: <200207301912.MAA15964@mutiny.2pi.org> On Tue, 30 Jul 2002 07:27:27 -0700 Chuq Von Rospach wrote: >On 7/30/02 3:41 AM, "Ka-Ping Yee" wrote: >> I think they'd hardly be able to get any. Have you really thought about >> how hard this would be? Why would they bother to invest the enormous >> development effort to make this work for the one or two addresses they >> *might* get, along with a large number of misread addresses? > >Yes, I have. Because I've seen how the spammers have moved up the technology >curve when it suited their purposes. > >You're depending on not being "the low hanging fruit", so to speak. That's >the philosophy behind "the club" for preventing car thefts. That philosophy >works only as long as your data isn't valuable enough to be worth the extra >effort. Once it does, you suddenly have a protection system that isn't >working, but you've created a false sense of security because you think it >works. That's worse than having no system, then, because you've stopped >being worried about it. > >> In the image case, there is no secret. Nobody knows how to program a >> computer to read as well as person can > >Have you seen what the off the shelf OCR systems like OmniPage do these >days? What's more, Gary Kopec and others at Xerox PARC developed OCR algorithms that, in many situations, can read much better than a person can. There are practical issues that prevent using these algorithms in the typical shrink-wrap OCR applications, but I think they'd work pretty well for converting email address images. There are probably one or two dozen people who could implement this in a few months, and lots who could do so after reading the papers that have been published. (There is an issue of patent infringement that might discourage selling such software, but it would be really hard to know that a big harvester was using the algorithms internally.) IOW, Chuq I think you're right on target: Once it becomes valuable enough to get around image-encoding of email addresses, then it will be done. Anyone for audio-encoded email addresses? When it comes to speech recognition, computers are definitely much worse than people. -les From barry@python.org Tue Jul 30 20:19:49 2002 From: barry@python.org (Barry A. Warsaw) Date: Tue, 30 Jul 2002 15:19:49 -0400 Subject: [Mailman-Developers] Almost OT: Re: Opening up a few can o' worms here... References: <200207301912.MAA15964@mutiny.2pi.org> Message-ID: <15686.59093.223547.540583@anthem.wooz.org> >>>>> "LN" == Les Niles writes: LN> Anyone for audio-encoded email addresses? When it comes to LN> speech recognition, computers are definitely much worse than LN> people. Maybe I can finally suck Tim Peters into the Mailman project, albeit in an obtuse way. He'll be tasked with writing the speech recognition software for the harvesters. :) -Barry From mjm@michaelmeltzer.com Tue Jul 30 21:09:58 2002 From: mjm@michaelmeltzer.com (Michael Meltzer) Date: Tue, 30 Jul 2002 16:09:58 -0400 Subject: [Mailman-Developers] Almost OT: Re: Opening up a few can o' wormshere... References: <200207301912.MAA15964@mutiny.2pi.org> Message-ID: <008101c23805$1424e770$34f820c0@ix1x1000> For what is worth, I think you are off in the wrong direction, you have to assume the "opposing side" is just as good as you are, any attempt to mask address will fail. It like bicycle lock in Manhattan, lock companies came out with all sort in "high tech" metal to defect thieves, it did not work in the end because the thieves found out "freezing" them the hitting it with a hammer defeated them all(no bike lock has insurance in Manhattan). The answer from the bike users was to make their bike not worth stealing :-) I think it is the same problem here, instead of trying to hiding the email address you should be reducing the value of having the email address. My first shot at the problem would be: 1) change all email address to a anonymous a address that points at the listserver (virtual tables) mjm@michaelmeltzer.com->1234-remail@python.org 2) Database email, newemail and the fingerprint all list member from their header, ip, received, software(all stuff that a bulk mailer will not have, hard/can not forge), most things not in most archives. 3)if another list member wants to email someone, check the senders fingerprints, if fail challenge them including their password. We are verifying the sender. About the only "opposing side" can do to get around this is by sining up to the list, use a real email account and send the bulk mail from the same SMTP server/domain(no value in selling a list). Even then a simple rate monintor could shut that down pretty quick(remember you are seeing all the email to the list members). 4)can keep multiple fingerprints for multiple machines. Only need one challenge for upgrade or isp change 5)remeber we are watching the sender were the problem is, the value of the email address is close to zero, no problem if someone puts a list in clear/ unprotected area. For what it is worth MJM ----- Original Message ----- From: "Les Niles" To: Sent: Tuesday, July 30, 2002 3:12 PM Subject: [Mailman-Developers] Almost OT: Re: Opening up a few can o' wormshere... > On Tue, 30 Jul 2002 07:27:27 -0700 Chuq Von Rospach wrote: > >On 7/30/02 3:41 AM, "Ka-Ping Yee" wrote: > >> I think they'd hardly be able to get any. Have you really thought about > >> how hard this would be? Why would they bother to invest the enormous > >> development effort to make this work for the one or two addresses they > >> *might* get, along with a large number of misread addresses? > > > >Yes, I have. Because I've seen how the spammers have moved up the technology > >curve when it suited their purposes. > > > >You're depending on not being "the low hanging fruit", so to speak. That's > >the philosophy behind "the club" for preventing car thefts. That philosophy > >works only as long as your data isn't valuable enough to be worth the extra > >effort. Once it does, you suddenly have a protection system that isn't > >working, but you've created a false sense of security because you think it > >works. That's worse than having no system, then, because you've stopped > >being worried about it. > > > >> In the image case, there is no secret. Nobody knows how to program a > >> computer to read as well as person can > > > >Have you seen what the off the shelf OCR systems like OmniPage do these > >days? > > What's more, Gary Kopec and others at Xerox PARC developed OCR > algorithms that, in many situations, can read much better than a > person can. There are practical issues that prevent using these > algorithms in the typical shrink-wrap OCR applications, but I think > they'd work pretty well for converting email address images. There > are probably one or two dozen people who could implement this in a > few months, and lots who could do so after reading the papers that > have been published. (There is an issue of patent infringement > that might discourage selling such software, but it would be really > hard to know that a big harvester was using the algorithms > internally.) IOW, Chuq I think you're right on target: Once it > becomes valuable enough to get around image-encoding of email > addresses, then it will be done. > > Anyone for audio-encoded email addresses? When it comes to speech > recognition, computers are definitely much worse than people. > > -les > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman-21/listinfo/mailman-developers From jerry@sandiego.edu Tue Jul 30 22:05:46 2002 From: jerry@sandiego.edu (Jerry Stratton) Date: Tue, 30 Jul 2002 14:05:46 -0700 Subject: [Mailman-Developers] Re: Opening up a few can o' worms here... In-Reply-To: References: Message-ID: > > Have you seen what the off the shelf OCR systems like OmniPage do these > > days? > >Yes -- the performance is awful. And that's on ordinary printed text >that's supposed to be readable, not on text that has been intentionally >obfuscated. My experience is otherwise; I use OmniPage 7.0--an old version on our Macs here at the school--to OCR out-of-copyright texts for placement on-line. All of these books are old, and many are dirty, ripped, and/or faded. Some are in strange fonts, tiny fontsizes, and multiple styles. Sometimes I can even see the text on the other side of the paper. OmniPage not only gets the correct text (sometimes text that I wasn't even sure about until I saw OmniPage's "guess"), but it also keeps the italicization, bolding, subscripts, and superscripts. It recognizes columns, and even recognizes and automatically reorients when I accidentally put the book in upside down. And this is from 1997 or earlier technology! Scanning has come a *long* way from the old Kurzweil washing-machine that we used to scan Freud's text back in the eighties. Jerry -- jerry@sandiego.edu http://www.sandiego.edu/~jerry/ Serra 188B/x8773 -- The more restrictions there are, the poorer the people become. The greater the government's power, the more chaotic the nation would become. The more the ruler imposes laws and prohibitions on his people, the more frequently evil deeds would occur. --The Silence of the Wise: The Sayings of Lao Zi From claw@kanga.nu Wed Jul 31 06:30:12 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 30 Jul 2002 22:30:12 -0700 Subject: [Mailman-Developers] Initial Mailman v2.0 with TMDA and Mime filtering Message-ID: <1262.1028093412@kanga.nu> This is mostly written for the Mailman MLM community, but is CCed to tmda-users as it applies there as well. In general subsequent discussion should happen on mailman-developers, so I've set Reply-To accordingly. I'm writing this now as the discussed configuration appears to work and I'd rather document it now while its still fresh in my mind then later when its not. If any big bugs or required changes surface I'll post on those later to the mailman-developers list. I built the system with Mailman 2.0, TMDA 0.58, Exim v3, mimefilter, mimedecode, and procmail. You don't need mimedecode or mimefilter, but if you want to do mime filtering (even with say strip mime or demime instead) adapting the below is should be simple and obvious. Several aspects and details are going to be specific to the default configurations and installations of the relevant packages under Debian Linux. I will assume that you'll be Linux/Unix savvy enough to both detect those points and work around them as needed. Background: -- I decided to integrate the system via procmail as I also wanted to (easily) add MIME filtering and other forms of message rewriting to my list setup. -- A primary goal is that the system operates without requiring either SysAdm or list owner attention. -- As discussed on-list One of my wishes was that lists maintain whitelists which are private to them and thus not shared across the entire set of lists serviced by that host. I will not detail how I went about that except in passing as current TMDA development initiatives will render that much simpler in future. -- Elegance was not a goal. Workability and were. There are several rough edges left. Some are noted below. How-To: ------- Getting the system working essentially has three steps: 1) Getting Mailman working transparently under Exim without aliases. 2) Getting TMDA configured, installed, and tested. 3) Getting TMDA integrated with Exim and Mailman, using procmail as a glue layer. You'll be wise to check and test each step as you go along. Finding the correct source of faults with the whole system in place can be a confusing and difficult exercise. Its easier to test and retest as you go along so as to limit the set of possible items that need examination for error. Step one is fairly simple: Just configure Exim as per the README.Exim or Nigel's HOW-TO on exim.org. Make sure its all working and that Mailman functions correctly in all regards as regards the MTA. You will have to update and extend these configurations later to suit TMDA, but start out making sure you have the base right. If Mailman doesn't work on your system its hardly worth trying to get TMDA also not working. Install TMDA on your system (Debian uses a $PREFIX of /usr). Make sure you get at least version 0.58. For Debian this means installing from /testing. If you use a later version (such as current CVS) read the changelog carefully as you'll have to make some adaption in your setup to the new features in TMDA. Those changes are left as an exercise for the reader. Under ~list/ creat the following directory hierarchy, with 0700 permissions and owned by list.list (the Debian Mailman user): ~list/.tmda ~list/.tmda/cache ~list/.tmda/lists ~list/.tmda/logs ~list/.tmda/filters ~list/.tmda/pending ~list/.tmda/templates Within that tree creat the following empty files, each of zero length, owned by list.list and with 0600 permissions: ~list/.tmda/lists/released ~list/.tmda/lists/whitelist.auto ~list/.tmda/lists/blacklist ~list/.tmda/lists/whitelist ~list/.tmda/filters/outgoing The above files need to be created as otherwise TMDA will error when it fails to find them. If you have particular scaling or performance issues with regard to these address lists you might want to use the dbm or cdb forms instead (see the TMDA documentation for details). If so, make sure you configure ~list/.tmda/config to match. Next copy the default TMDA message templates to: ~list/.tmda/templates/bounce.txt ~list/.tmda/templates/confirm_request.txt ~list/.tmda/templates/confirm_accept.txt And rewrite them as suitable for your mailing lists. Now create your TMDA crypt key in: ~list/.tmda/crypt_key and your TMDA configuration in: ~list/.tmda/config My ~list/.tmda/config reads: DATADIR = "/var/lib/mailman/.tmda/" MAIL_TRANSFER_AGENT = "exim" DELIVERY = "|/usr/bin/procmail -p -f $SENDER" RECIPIENT_DELIMITER = "+" CRYPT_KEY_FILE = "/var/lib/mailman/.tmda/crypt_key" BARE_APPEND = "/var/lib/mailman/.tmda/lists/whitelist" CONFIRM_APPEND = "/var/lib/mailman/.tmda/lists/whitelist.auto" CONFIRM_MAX_MESSAGE_SIZE = None TEMPLATE_DIR = "/var/lib/mailman/.tmda/templates/" ACTION_INCOMING = "confirm" ACTION_OUTGOING = "bare" FINGERPRINT = ["message-id", "from", "date"] FULLNAME = "List Filter System" HOSTNAME = "kanga.nu" LOGFILE_DEBUG = "/var/lib/mailman/.tmda/logs/tmda_debug.log" LOGFILE_INCOMING = "/var/lib/mailman/.tmda/logs/tmda_incoming.log" PENDING_BLACKLIST_APPEND = "/var/lib/mailman/.tmds/lists/blacklist" PENDING_BLACKLIST_APPEND = "/var/lib/mailman/.tmds/lists/deleted" PENDING_RELEASE_APPEND = "/var/lib/mailman/.tmda/lists/released" PENDING_WHITELIST_APPEND = "/var/lib/mailman/.tmda/lists/whitelist" TIMEOUT = "2w" You'll specifically need to tailor the values of FULLNAME and HOSTNAME from the above cases. Note: I use a RECIPIENT_DELIMITER of "+" as I use "-" in several list names and don't want the two appearing to run together. Make sure you read the caveats on using "+" in the TMDA FAQ before chosing the RECIPIENT_DELIMITER you want to use. In my case ~list/.tmda/logs is actually a symlink to /var/log/TMDA which is owned by list.list and of 0700 permissions and a matching logrotate stanza: /var/log/TMDA/procmail.log { monthly compress missingok } /var/log/TMDA/tmda-debug.log { monthly compress missingok } /var/log/TMDA/tmda-incoming.log { monthly compress missingok } Next, and almost finally is to create the incoming filter with ownership list.list and permissions 0600: ~list/.tmda/filters/incoming The contents should be similar to: # # Note: First match wins, so sequence of rules is significant # # # Bounce blacklisters # from-file ~list/.tmda/lists/blacklist bounce # # Explicitly listed whitelist addresses get thru (explicitly because # this is a hand maintained file) # from-file ~list/.tmda/lists/whitelist ok # # Normal list members get thru. Repeat this line as needed for each # of your lists, replacing "listname" with each listname. # from-mailman -attr=members ~list/lists/listname ok # # Digest members get thru. Repeat this line as needed for each of # your lists, replacing "listname" with each listname # from-mailman -attr=digest_members ~list/lists/listname ok # # Confirmed whitelist addresses get thru (the whitelist.auto file is # built by posters confirming themselves to TMDA) # from-file ~list/.tmda/lists/whitelist.auto ok # # Mail from the list control gets thru. Repeat these lines as needed # for each of your lists, replacing "listname" with each listname. # from listname-admin@kanga.nu ok from listname-owner@kanga.nu ok Tailor to suit as noted. Soon the complexity (and hand effort of adding the list-specific lines) will no longer be necessary as future versions of TMDA will have a more flexible filter schema that supports variable replacement. At this point you should be able to test your TMDA configuration (not including the Mailman specific bits), manually injecting messages into tmda-inject while having the environment variables SENDER and RECIPIENT appropriately set and seeing that it doesn't error (check the bounces and ~list/.tmda/logs/tmda-debug.log for specifics on errors). Check your TMDA setup carefully and pay particular attention to file permissions and ownership errors. Make sure you do all your testing as the Mailman user ("list" for Debian). You're now ready for the last step: integrating TMDA with Exim via procmail. Place the procmail rc in: ~list/.procmailrc Again, the ownership is list.list and permissions 0600. It should read something like: VERBOSE=off SHELL=/bin/sh PATH=/usr/bin:/usr/local/bin:/usr/lib:/usr/local/lib LOGFILE=/var/log/TMDA/procmail.log MAILDIR=/var/lib/mailman/locks # # Commands don't get filtered # :0 w * ACTION ?? mailcmd |/var/lib/mailman/mail/wrapper $ACTION $TARGET # # Pass bounces thru directly. # :0 w * ACTION ?? mailowner * ^Return-path: <> | /var/lib/mailman/mail/wrapper $ACTION $TARGET # # Mail that has already been filtered by TMDA. This is an added # header that is used to check for messages which have already been # processed by this TMDA/Mailman procmail filter. # :0 w * $^X-Mail-Filter-Recipient: $RECIPIENT { # # Send the message to Mailman for processing. This is a separate # recipe to make the extensions for MIME filter etc below clearer # and simpler. # :0 w * ACTION ?? post | /var/lib/mailman/mail/wrapper $ACTION $TARGET :0 w * ACTION ?? mailowner | /var/lib/mailman/mail/wrapper $ACTION $TARGET } # # Add the flag header so we can detect messages coming out of TMDA, # even as distinct from mail from other TMDA users. # :0 fw | /usr/bin/formail -A "X-Mail-Filter-Recipient: $RECIPIENT" # # Everything else (-admin, -owner, and posts which haven't been # passed by TMDA) get filtered thru tmda-filter. If you want # list-specific inbound filters instead globally shared lists, # insert a small script here which writes a message customised # inbound filter in (say) /tmp/tmda-inbound.$$, call tmda-filter # with a matching -I argument, and then delete the temporary inbound # filter afterwards. # :0 w | /usr/bin/tmda-filter -c /var/lib/mailman/.tmda/config # # Take the exit code from TMDA. This allows procmail to return in # error to the MTA. # EXITCODE=$? Notes: 1) Please use a different loop detection header than X-Mail-Filter-Recipient. Make something up that fits your needs. 2) The added loop detection will not be necessary with TMDA versions after 0.58 as they add their own custom header which you can use for host and recipient specific loop detection. As I do want to do MIME and other message pre-processing, and I want the ability to send messages which bypass the MIME filters, my ~list/.procmailrc is a little more complex. Adapt as appropriate to your installation: VERBOSE=off SHELL=/bin/sh PATH=/usr/bin:/usr/local/bin:/usr/lib:/usr/local/lib LOGFILE=/var/log/TMDA/procmail.log MAILDIR=/var/lib/mailman/locks # # Commands don't get filtered # :0 w * ACTION ?? mailcmd |/var/lib/mailman/mail/wrapper $ACTION $TARGET # # Pass bounces thru directly. # :0 w * ACTION ?? mailowner * ^Return-path: <> | /var/lib/mailman/mail/wrapper $ACTION $TARGET # # Mail that has already been filtered by TMDA. This is an added # header that is used to check for messages which have already been # processed by this TMDA/Mailman procmail filter. # :0 w * $^X-Kanga-Mail-Filter-Recipient: $RECIPIENT { # # Posts sent to a list # :0 w * ACTION ?? post { # # Got an X-MimeStripNo header? Don't MIME strip # :0 w * ^X-MimeStripNo { # # Remove the X-MimeStripNo header # :0 fw | formail -I X-MimeStrip } :0 w * ! ^X-MimeStripNo { # # Mimefilter -- As mimefilter requires that the local directory # be writable and that various environment variables are defined, # we use a wrapper script. # :0 fw | ~archiver/bin/MimeFilter # # Get rid of quoted-printable # :0 fw | /usr/bin/mimedecode } # # If there's nothing left of the message (less than 20 bytes), don't # bother sending it forward to Mailman. # :0 wb * < 20 | /dev/null # # We have a post! # :0 w | /var/lib/mailman/mail/wrapper $ACTION $TARGET } # # Messages to -admin and -ower # :0 w * ACTION ?? mailowner | /var/lib/mailman/mail/wrapper $ACTION $TARGET } # # Add the flag header so we can detect posts coming out of TMDA, # even as distinct from mail from other TMDA users. # :0 fw | /usr/bin/formail -A "X-Kanga-Mail-Filter-Recipient: $RECIPIENT" # # Everything else (-admin, -owner, and posts) get filtered thru TMDA # :0 w | /usr/bin/tmda-filter -c /var/lib/mailman/.tmda/config # # Take the exit code from TMDA. This allows procmail to return in # error to the MTA. # EXITCODE=$? Yeah, I could make that procmailrc cleaner and simpler. It works. Its a 1.0. I don't argue with working 1.0 versions. The contents of ~archiver/bin/MimeFilter are: #!/bin/bash #set -x # # Syntax: # # MimeStrip # # Author: J C Lawrence # # -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= # Config (Edit this bit to suit your setup!) # -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= # Where is mimefilter? mimefilter="/usr/bin/mimefilter" # Note: Make sure that the value of tmpdir is writeable by the UID or GID # that this script will execute under. tmpdir="/tmp/mimestrip.${$}" # Do you want to save an mbox of the messages before filtering # in $savefile_pre? (0/1) feature_savepre=1 # Do you want to save an mbox of the messages after filtering # in $savefile_post? (0/1) feature_savepost=1 # File to save pre-filtered messages in savefile_pre="/tmp/mimestrip.prefilter" # File to same post filtered messages in savefile_post="/tmp/mimestrip.postfilter" # -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= # MimeFilter setup (Don't edit from here down) # -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= # The name of the mailing list this message is intended for. Used # as the return address of the warning issued to the orginal author # if the message is not already clean. export list=${USER} # The address of the mailing list this message is intended for. # Used in the X-Loop field of the warning issued to the original # author if the message is not already clean. export listaddr=${USER}@${DOMAIN} # The administrative (owner) address of the mailing list this # message is inteded for. Used in the return address of the warning # issued to the original author if the message is not already clean. export listreq=${USER}-admin@${DOMAIN} # The email address of the maintainer of the mailing list this # message is inteded for. If it is defined, it is used to send the # maintainer original carbon copies of messages that have been # modified by this filter -- if filter_mime_cc_maintainer is # affermative, of course. export maintainer=${USER}-owner@${DOMAIN} # A boolean flag: if affermative (i.e., if it matches the /y/i Perl # regular expression), the mimefilter script will send carbon copies # of every cleaned (modified) message to the maintainer of the # mailing list the message is intended for. export filter_mime_cc_maintainer=${copy_maintainer} # -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= # Start working # -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= # Build a safe working directory for mimefilter. We need to do this as # postfix by default will execute this script in /var/spool/postfix and # mimefilter will try and create temp directories and files under there, # which will fail on permissions. # Note: Make sure that the value of tmpdir is writeable by the UID or GID # that this script will execute under. /bin/rm -rf ${tmpdir} 2> /dev/null /bin/mkdir ${tmpdir} cd ${tmpdir} /bin/cat | ${mimefilter} # Save copies of the before and after messages off to a temp file for # analysis/debugging if [ ${feature_savepre} -eq 1 ] then /bin/cat ${holdfile} >> ${savefile_pre} echo >> ${savefile_pre} fi if [ ${feature_savepost} -eq 1 ] then /bin/cat ${workfile} >> ${savefile_post} echo >> ${savefile_post} fi # Clean up /bin/rm -rf ${tmpdir} exit Most of all that hassle is to get the environment variables mimefilter needs properly set and get the current working directory set to something I've write permissions to (eg /tmp). I could have done all that inside procmail (and probably should have). I didn't for purely historical reasons. mimedecode is a little tool which flattens quoted-printable into US ASCII. I find it rather useful. Take care here if you have posters posting with other character sets. As always: caveat emptor. At this point you should be able to test your procmail and TMDA configuration my injecting messages into procmail as below: # List posts cat message_file | procmail -mpt ACTION='post' TARGET='listname' ~list/.procmailrc # -request commands cat message_file | procmail -mpt ACTION='mailcmd' TARGET='listname' ~list/.procmailrc # -admin and -owner messages cat message_file | procmail -mpt ACTION='mailowner' TARGET='listname' ~list/.procmailrc Test it all out. Make sure TMDA is properly holding messages. Release, whitelist, blacklist etc them via: tmda-pending -c ~list/.tmda/config and watch the contents of ~list/.tmda/lists to ensure that the right things are happening. Work the whole system until you're certain that everything in the procmailrc and your TMDA configuration has been exercised and shown correct. Don't forget to go back and delete all your test addresses from the files under ~list/.tmda/lists. Remember to NOT delete the files and to do all your testing as the list user (file permissions are critical). You're now ready for the last step: Integrating with your MTA. Before we get to the message details some discussion on why I used Exim for this: I started out wanting and trying to use Postfix. The core problem I hit was making the filter process hung off the alias execute as the right user. I needed it to execute as the list user so it would be able to read the Mailman list configurations to verify subscribers from there. If you want to entirely separate posting rights from list subscription this wouldn't be a problem (just remove the mailman bits from ~list/filters/incoming). Getting the filter process to execute as 'list' under postfix proved a bitch. Its not impossible, but it requires either messing with content filters (which have a high performance overhead for ALL messages) or doing a vtable setup with a custom transport, which requires that you run your lists from a sub-domained virtual host (eg lists.kanga.nu). I am unwilling to make either compromise. YMMV. Exim conversely makes defining the specific effective UID and GID for an alias filter process very easy. I also like, know, and use Exim on other systems, so moving my list server back to Exim was no great pain. I don't like and refuse to use either Sendmail, and so can't comment on how TMDA may be integrated with it. I'm also not a QMail user and so can't comment for similar reasons. For those familiar with those respective MTAs you should be able to base off the below recipes (with the above caveats) successfully. The full set of Mailman-specific sections needed in /etc/exim/exim.conf are as below. Compare them carefully with the Nigel's HOW-TO for basic Exim/Mailman integration. The changes aren't large but you should understand each of them. The documentation at exim.org is excellent. These configurations are mildly Exim v3 specific. Exim v4 is noticeably but not fundamentally different. Use the documentation at exim.org to guide you thru the differences. In the main configuration section: # Add the Mailman user (list) to the value of trusted users so # procmail can use -p to pass environment variables through # (required by TMDA) trusted_users = mail:list # $HOME dir for Mailman MAILMAN_HOME=/var/lib/mailman # Wrapper script for Mailman MAILMAN_WRAP=MAILMAN_HOME/mail/wrapper # UID and GID for Mailman MAILMAN_UID=list MAILMAN_GID=mail In the transports section: list_transport: driver = pipe command = /usr/bin/procmail -mpt ACTION='post' TARGET='${lc:$local_part}' MAILMAN_HOME/.procmailrc # command = MAILMAN_WRAP post ${lc:$local_part} current_directory = MAILMAN_HOME home_directory = MAILMAN_HOME user = MAILMAN_UID group = MAILMAN_GID return_path_add delivery_date_add envelope_to_add environment = EXTENSION=${substr_1:$local_part_suffix}:\ RECIPIENT=$local_part$local_part_suffix@$domain list_request_transport: driver = pipe command = /usr/bin/procmail -mpt ACTION='mailcmd' TARGET='${lc:$local_part}' MAILMAN_HOME/.procmailrc # command = MAILMAN_WRAP mailcmd ${lc:$local_part} current_directory = MAILMAN_HOME home_directory = MAILMAN_HOME user = MAILMAN_UID group = MAILMAN_GID return_path_add delivery_date_add envelope_to_add environment = EXTENSION=${substr_1:$local_part_suffix}:\ RECIPIENT=$local_part$local_part_suffix@$domain list_admin_transport: driver = pipe command = /usr/bin/procmail -mpt ACTION='mailowner' TARGET='${lc:$local_part}' MAILMAN_HOME/.procmailrc # command = MAILMAN_WRAP mailowner ${lc:$local_part} current_directory = MAILMAN_HOME home_directory = MAILMAN_HOME user = MAILMAN_UID group = MAILMAN_GID return_path_add delivery_date_add envelope_to_add environment = EXTENSION=${substr_1:$local_part_suffix}:\ RECIPIENT=$local_part$local_part_suffix@$domain In the directors section: list_owner_director: driver = smartuser require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.db suffix = "-owner" new_address = "${lc:$local_part}-admin@${domain}" owner_list_director: driver = smartuser require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.db prefix = "owner-" new_address = "${lc:$local_part}-admin@${domain}" list_admin_director: driver = smartuser suffix = -admin require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.db transport = list_admin_transport list_request_director: driver = smartuser suffix = -request require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.db transport = list_request_transport list_director: driver = smartuser require_files = MAILMAN_HOME/lists/${lc:$local_part}/config.db transport = list_transport suffix = +* suffix_optional Pay particular attention to the value of "suffix" in list-director and make sure it agrees with RECIPIENT_DELIMITER in ~list/.tmda/config. You should now be up and running with TMDA integrated as the front face of your Mailman lists. If you want to monitor your TMDA pending queue for your Mailman installation you can periodically run tmda-pending -c ~list/.tmda/config Or just drop the following cronjob in the Mailman user's crontab: * * * * * /usr/bin/tmda-pending -CTb | mail you@domain.tld to be emailed regular status updates on new messages in TMDA pending. Enjoy. -- 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 claw@kanga.nu Wed Jul 31 06:46:45 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 30 Jul 2002 22:46:45 -0700 Subject: [Mailman-Developers] Initial Mailman v2.0 with TMDA and Mime filtering In-Reply-To: Message from J C Lawrence of "Tue, 30 Jul 2002 22:30:12 PDT." <1262.1028093412@kanga.nu> References: <1262.1028093412@kanga.nu> Message-ID: <1432.1028094405@kanga.nu> On Tue, 30 Jul 2002 22:30:12 -0700 J C Lawrence wrote: > I'm writing this now as the discussed configuration appears to work > and I'd rather document it now while its still fresh in my mind then > later when its not. If any big bugs or required changes surface I'll > post on those later to the mailman-developers list. Its now section 6.7 in the mailman user FAQ: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.007.htp -- 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 claw@kanga.nu Wed Jul 31 07:54:39 2002 From: claw@kanga.nu (J C Lawrence) Date: Tue, 30 Jul 2002 23:54:39 -0700 Subject: [Mailman-Developers] Initial Mailman v2.0 with TMDA and Mime filtering In-Reply-To: Message from J C Lawrence of "Tue, 30 Jul 2002 22:46:45 PDT." <1432.1028094405@kanga.nu> References: <1262.1028093412@kanga.nu> <1432.1028094405@kanga.nu> Message-ID: <1975.1028098479@kanga.nu> On Tue, 30 Jul 2002 22:46:45 -0700 J C Lawrence wrote: > On Tue, 30 Jul 2002 22:30:12 -0700 J C Lawrence wrote: >> I'm writing this now as the discussed configuration appears to work >> and I'd rather document it now while its still fresh in my mind then >> later when its not. If any big bugs or required changes surface I'll >> post on those later to the mailman-developers list. > Its now section 6.7 in the mailman user FAQ: > http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.007.htp If you want to play with a list set up this way I still have my list installation running. Give me a shout and I'll send over the addresses etc. Abusers will of course get blacklisted. -- 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 Nigel.Metheringham@dev.InTechnology.co.uk Wed Jul 31 09:10:39 2002 From: Nigel.Metheringham@dev.InTechnology.co.uk (Nigel Metheringham) Date: 31 Jul 2002 09:10:39 +0100 Subject: [Mailman-Developers] Cute TMDA use In-Reply-To: <24907.1028049622@kanga.nu> References: <3D4655E2.74D82F1E@mail.dcu.ie> <1028040233.23063.111.camel@gaspode.localnet> <24692.1028048970@kanga.nu> <15686.51538.28466.776823@anthem.wooz.org><24907.1028049622@kanga.nu> Message-ID: <1028103040.28019.2.camel@gaspode.localnet> On Tue, 2002-07-30 at 18:20, J C Lawrence wrote: > On Tue, 30 Jul 2002 13:13:54 -0400 > Barry A Warsaw wrote: > > Not necessarily. Mailman's replybot can be set up to provide that > > information to them during the confirmation handshake. > > Yes, but the point (I think) is that Nathan wants something explicitly > linked against posting versus subscribing or other generic list > activity. We've been exchanging emails for so long and you forget my name (sob) :-) As long as everyone posting to the list has been informed of list policy such as archiving I'm happy. So one time posters get that through TDMA, members get it through the subscription. > Nathan has already stated he's interested in some of the legal CYA, and > for that (I expect) he needs an explicit decision at the time of first > post, not first subscribe. I need them to have been informed. If they forget thats *their* problem. Nigel. -- [ Nigel Metheringham Nigel.Metheringham@InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From barry@python.org Wed Jul 31 15:39:52 2002 From: barry@python.org (Barry A. Warsaw) Date: Wed, 31 Jul 2002 10:39:52 -0400 Subject: [Mailman-Developers] Initial Mailman v2.0 with TMDA and Mime filtering References: <1262.1028093412@kanga.nu> <1432.1028094405@kanga.nu> Message-ID: <15687.63160.812836.586134@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: JCL> Its now section 6.7 in the mailman user FAQ: Thanks JC. Would you mind writing up a couple of paragraphs of motivation for inclusion in a README.TMDA file? E.g. Why did you go through all this effort? What problem were you trying to solve? Maybe: why did you choose this particular toolset? It doesn't need to go into any of the detail of your FAQ entry. We'll just include a reference to it and be done. Thanks, -Barry From noreply@sourceforge.net Wed Jul 31 17:43:41 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jul 2002 09:43:41 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-588373 ] bug with 2.1b2 (something with cookies?) Message-ID: Bugs item #588373, was opened at 2002-07-29 23:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=588373&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Marshall (paulmarshll) Assigned to: Nobody/Anonymous (nobody) Summary: bug with 2.1b2 (something with cookies?) Initial Comment: This is hopefully my third and final stupid question involving mailman. I have mailman 2.1b2 setup and mostly working (I can create lists, and post, etc...). However whenever I try to log into a list via the admin page to edit/delete/whatever to it, it comes up with this bug: Traceback (most recent call last): File "/var/mailman/scripts/driver", line 82, in run_main main() File "/var/mailman/Mailman/Cgi/admin.py", line 82, in main cgidata.getvalue('adminpw', '')): File "/var/mailman/Mailman/SecurityManager.py", line 208, in WebAuthenticate print self.MakeCookie(ac, user) File "/var/mailman/Mailman/SecurityManager.py", line 223, in MakeCookie c = Cookie.SimpleCookie() AttributeError: 'module' object has no attribute 'SimpleCookie' Is this a permissions problem? something to do with creating cookies...Honestly, I have no idea... I've searched some bug databases and most likely passed right over it, however I can't seem to find anything dealing with this error. Thanks for all the help. Paul ---------------------------------------------------------------------- >Comment By: Paul Marshall (paulmarshll) Date: 2002-07-31 11:43 Message: Logged In: YES user_id=582441 I fixed the problem. Apparently I still had Cookie.py and Cookie.pyc, which I deleted, this seemed to fix the problem. Found this on: http://mail.python.org/pipermail-21/mailman-developers/2001- November/010020.html Thanks anyways. This post can be deleted. Paul ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=588373&group_id=103 From noreply@sourceforge.net Wed Jul 31 18:01:40 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jul 2002 10:01:40 -0700 Subject: [Mailman-Developers] [ mailman-Patches-573508 ] ToUsenet: subject prefix stripping Message-ID: Patches item #573508, was opened at 2002-06-25 02:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=573508&group_id=103 >Category: mail delivery >Group: Mailman 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Mark Weaver (mdw21) Assigned to: Nobody/Anonymous (nobody) Summary: ToUsenet: subject prefix stripping Initial Comment: For some inexplicable reason ToUsenet is trying to -add- the subject prefix. Now this doesn't work generally anyway (consider a plain post - this won't do it). Typically, the subject prefix is the list- name, which just replicates information we already have (as we already know which newsgroup we are looking at). Anyway, arguments aside, I've fixed up ToUsenet.py to go the other way and remove subjects. (I would have made this an option, but my Python is non-existent). ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-31 13:01 Message: Logged In: YES user_id=12800 This patch is only relevant to MM2.0, and that version is in critical bug fix phase only. MM2.1 does it differently, but I'm wondering if the subject should not be added to news bound messages either? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=573508&group_id=103 From noreply@sourceforge.net Wed Jul 31 18:02:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jul 2002 10:02:21 -0700 Subject: [Mailman-Developers] [ mailman-Patches-573509 ] ToUsenet: subject prefix stripping Message-ID: Patches item #573509, was opened at 2002-06-25 02:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=573509&group_id=103 Category: None Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Mark Weaver (mdw21) Assigned to: Nobody/Anonymous (nobody) Summary: ToUsenet: subject prefix stripping Initial Comment: For some inexplicable reason ToUsenet is trying to -add- the subject prefix. Now this doesn't work generally anyway (consider a plain post - this won't do it). Typically, the subject prefix is the list- name, which just replicates information we already have (as we already know which newsgroup we are looking at). Anyway, arguments aside, I've fixed up ToUsenet.py to go the other way and remove subjects. (I would have made this an option, but my Python is non-existent). ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-31 13:02 Message: Logged In: YES user_id=12800 This is a duplicate of 573508 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=573509&group_id=103 From JasonR.Mastaler Wed Jul 31 18:13:40 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Wed, 31 Jul 2002 11:13:40 -0600 Subject: [Mailman-Developers] Re: Initial Mailman v2.0 with TMDA and Mime filtering References: <25772.2319839106$1028093506@news.gmane.org> Message-ID: J C Lawrence writes: > I'm also not a QMail user and so can't comment for similar > reasons. I should have a Mailman/TMDA/qmail HOWTO ready shortly. And, it's significantly less complex that what was detailed here. It's based on the dot-qmail interface, and so doesn't require any changes to qmail, doesn't use procmail, etc. Stay tuned. -- (http://tmda.net/) From JasonR.Mastaler Wed Jul 31 18:33:02 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Wed, 31 Jul 2002 11:33:02 -0600 Subject: [Mailman-Developers] Re: Initial Mailman v2.0 with TMDA and Mime filtering References: <25772.2319839106$1028093506@news.gmane.org> Message-ID: J C Lawrence writes: > I built the system with Mailman 2.0, TMDA 0.58, Exim v3, mimefilter, > mimedecode, and procmail. After reading through this, my only concern is that it will only appeal to very few users. * It's too Exim specific. Exim is used less than Sendmail, Postfix or qmail. It would be nice to come up with a more general HOWTO that covers integration with either Sendmail, Postfix or Exim. * The mimefilter/mimedecode stuff is a distraction IMO, and not really relevant to the TMDA integration. * If we can find a way to do this without procmail, that's a bonus. That said, thanks for writing this up. I think it's a good start, and longer overdue. > I started out wanting and trying to use Postfix. The core problem > I hit was making the filter process hung off the alias execute as > the right user. I needed it to execute as the list user so it > would be able to read the Mailman list configurations to verify > subscribers from there. In the qmail HOWTO I'm writing, TMDA is driven from ~mailman's .qmail files, following the setup recommended in README.QMAIL. This solves the problem of access to the MM config.db files of course. > Getting the filter process to execute as 'list' under postfix > proved a bitch. What user is the filter process executed as by default? -- (http://tmda.net/) From claw@kanga.nu Wed Jul 31 18:33:12 2002 From: claw@kanga.nu (J C Lawrence) Date: Wed, 31 Jul 2002 10:33:12 -0700 Subject: [Mailman-Developers] Initial Mailman v2.0 with TMDA and Mime filtering In-Reply-To: Message from barry@python.org (Barry A. Warsaw) of "Wed, 31 Jul 2002 10:39:52 EDT." <15687.63160.812836.586134@anthem.wooz.org> References: <1262.1028093412@kanga.nu> <1432.1028094405@kanga.nu> <15687.63160.812836.586134@anthem.wooz.org> Message-ID: <7660.1028136792@kanga.nu> On Wed, 31 Jul 2002 10:39:52 -0400 Barry A Warsaw wrote: >>>>>> "JCL" == J C Lawrence writes: JCL> Its now section 6.7 in the mailman user FAQ: > Thanks JC. Welcome. > Would you mind writing up a couple of paragraphs of motivation for > inclusion in a README.TMDA file? E.g. Why did you go through all this > effort? What problem were you trying to solve? Maybe: why did you > choose this particular toolset? > It doesn't need to go into any of the detail of your FAQ entry. We'll > just include a reference to it and be done. Sure (I've not added the below to the FAQ -- please feel free to): Among of the basic problems if operating mailing lists are control and handling of valid posts from non-subscribers to a list, and control of SPAM. The two problems are related but not identical. Proper handling of posts from non-subscribed addresses can be a significant problem. SPAM comes from non-subscribed addresses (and is easily detected when it doesn't), but there are also more interesting cases; such as for (technical) support lists where the people reporting a bug have no real wish or need to subscribe to the list, for university students whose schools seemingly randomly rewrite their email addresses, or even just the people who have multiple email addresses and never quite remember which one they subscribed with. There are many useful cases beyond that where desirable list mail is sent from non-subscribed addresses. The standard answer to the fellow with multiple email addresses is that he should subscribe them all and set all but one to NoMail -- neither an attractive or particularly approach, especially if he moves jobs or IPSs with frequency, or he does not have direct control over what address is pasted onto the email he sends (more common than you may think). It also tends to leave your subscriber roster cluttered with increasing numbers of NoMail accounts over time as people leave the list and don't bother to unsubscribe addresses which don't get list mail. Properly or effectively handling SPAM is a near universal problem. The current cold war between SPAMmers and SPAM detection systems like SpamAssassin leave far too much SPAM getting through. While SPAM can be effectively controlled at a list's moderation interface, its expensive on the moderator's time and attention. The -owner and -admin addresses pose a larger problem: Commonly the -admin and -owner addresses for well known mailing lists receive hundreds if not thousands of SPAM for every valid message to them. TMDA (http://www.tmda.net/) can effectively address and help both problems. Loosely, TMDA is a "whitelist system". A whitelist system is an automated system of building lists of known-good or known-bad email addresses, and then filtering mail on the basis of those lists. TMDA does quite a bit more than this, but we're primarily interested in its whitelist management at this time. Note: The list of subscribed addresses that Mailman maintains for each list is effectively a whitelist. As each address is confirmed at subscription time it is both known to be a valid address, and the address of someone who is interested in the list. Putting TMDA in front of Mailman can gain the following behaviors: All mail send to any of the list related addresses (list itself, -owner and -admin) passes through the TMDA filter system and: a) As TMDA can read and process Mailman config.db files (where the subscriber data is) mail from subscribers (who have effectively whitelisted themselves by confirming their address at subscription time) goes straight through to the list or -owner or -admin addresses. b) Mail from blacklisted addresses is silently discarded c) Mail from whitelisted addresses is passed through to the list or -owner or -admin addresses. d) All other mail is held by TMDA. TMDA then provides a confirmation system for held mail by sending a message back to the address that sent the held message, requesting confirmation that the poster not only exists, but really meant to send that message. The confirmation message contains both instructions on how to confirm, and a copy of the original message. If the original sender follows the instructions in the confirmation request the held message will be sent straight through to the list or or -owner or -admin addresses as if TMDA had never intercepted it. Further, TMDA will add that address to its whitelist so that future email from that address will pass straight through TMDA and not be held. In this manner non-subscribers can post to the list without having to subscribe a NoMail account or putting more load on the list moderator. If the original sender doesn't confirm his message TMDA will hold it for a while awaiting confirmation before silently deleting it. As SPAMers almost universally don't run proper mail systems they never receive the confirmation requests from TMDA and so never confirm and thus their messages never get to the list, -owner, or -admin. While it is possible that the very few SPAMmers who do run proper mail systems could build systems that can confirm TMDA requests (I haven't heard of even one yet that does), their population is so low, and they are so easily detected, that the effort of manually blacklisting them is not so large. Should SPAMmers get the hang of TMDA, TMDA can trivially change its confirmation process to be less and less automateble -- essentially making the confirmation process more and more of a Turing test. Happily, that's not necessary yet. The current TMDA method of, "Just reply to this message to confirm," works well for now. The end result is that subscription and posting rights for TMDA-fronted lists have effectively been separated. You now subscribe to a list to receive mail from the list (and establish an initial address from which you can post to the list). You simply send mail to the list (and confirm each email address) to be able to send messages to a list. Inserting TMDA in this manner in front of the -owner and -admin addresses has the following results: -- Mail from subscribers and other whitelisted addresses gets pass straight through to the list owner. -- Mail from other addresses is held for confirmation. In this way the primary audience (your list subscribers and whitelist members) can message the -owner or -admin without any extra effort. Other people merely need to confirm their address to gain the same benefit. Note: TMDA is a very flexible system. The above details one possible application and configuration of TMDA with mailman. Other simple variations could have every inbound message needing to be confirmed, every message from a non-subscriber needing confirmation, having TMDA manage all posting rights and never checking the Mailman list subscriber list, etc. TMDA also supports a significant feature set over and above just whitelist handling. There are very interesting things that can be done with TMDA's custom addresses for instance. Read the TMDA documentation and adapt the following HOW-TO to suit your needs. -- 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 fil@rezo.net Wed Jul 31 18:55:44 2002 From: fil@rezo.net (Fil) Date: Wed, 31 Jul 2002 19:55:44 +0200 Subject: [Mailman-Developers] Initial Mailman v2.0 with TMDA and Mime filtering In-Reply-To: <7660.1028136792@kanga.nu> References: <1262.1028093412@kanga.nu> <1432.1028094405@kanga.nu> <15687.63160.812836.586134@anthem.wooz.org> <7660.1028136792@kanga.nu> Message-ID: <20020731175544.GB25611@rezo.net> > TMDA then provides a confirmation system for held mail by sending a > message back to the address that sent the held message, requesting > confirmation that the poster not only exists, but really meant to send > that message. The confirmation message contains both instructions on > how to confirm, and a copy of the original message. This is really neat, I'm eager to see it in action ASAP. A simple question though: does TMDA read the "language" data of the mailman list, and does/can it send the confirmation message in that language (when available)? Or are we going to have to wait for a fuller integration to enjoy this in i18n? -- Fil From claw@kanga.nu Wed Jul 31 19:13:03 2002 From: claw@kanga.nu (J C Lawrence) Date: Wed, 31 Jul 2002 11:13:03 -0700 Subject: [Mailman-Developers] Re: Initial Mailman v2.0 with TMDA and Mime filtering In-Reply-To: Message from Jason R. Mastaler of "Wed, 31 Jul 2002 11:13:40 MDT." References: <25772.2319839106$1028093506@news.gmane.org> Message-ID: <8127.1028139183@kanga.nu> On Wed, 31 Jul 2002 11:13:40 -0600 Jason R Mastaler wrote: > J C Lawrence writes: >> I'm also not a QMail user and so can't comment for similar reasons. > I should have a Mailman/TMDA/qmail HOWTO ready shortly. And, it's > significantly less complex that what was detailed here. Note that a significant portion of the complexity in my HOW-TO comes from shoving procmail into the pipe so i can add MIME filters and other other message processing tools in addition to TMDA. Doing just a straight TMDA/Mailman setup would have involved only edits to the Exim transports. -- 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 claw@kanga.nu Wed Jul 31 19:25:28 2002 From: claw@kanga.nu (J C Lawrence) Date: Wed, 31 Jul 2002 11:25:28 -0700 Subject: [Mailman-Developers] Re: Initial Mailman v2.0 with TMDA and Mime filtering In-Reply-To: Message from Jason R. Mastaler of "Wed, 31 Jul 2002 11:33:02 MDT." References: <25772.2319839106$1028093506@news.gmane.org> Message-ID: <8260.1028139928@kanga.nu> On Wed, 31 Jul 2002 11:33:02 -0600 Jason R Mastaler wrote: > J C Lawrence writes: >> I built the system with Mailman 2.0, TMDA 0.58, Exim v3, mimefilter, >> mimedecode, and procmail. > * It's too Exim specific. Exim is used less than Sendmail, Postfix or > qmail. It would be nice to come up with a more general HOWTO that > covers integration with either Sendmail, Postfix or Exim. Given that the alias filter has to execute as a specific effective UID/GID any HOW-TO is necessarily going to be MTA specific. There is no agreement or common standard among MTAs for configuring that. NOTE: IF TMDA were integrated with Mailman directly (eg plugin) this problem would be obviated. TMDA would be run by the Mailman processes which are already configured under the MTA to run as the appropriate UID. As such a very large portion of the problem and complexity automatically goes away at that point. Ditto with MIME filters and other post and pre-processing being plugins into the queue structure of Mailman v2.1. The attraction of Exim in this regard is that it makes such configuration both easy and very obvious/transparent, and you don't need to maintain any per-list configurations (such as an alias file). > * The mimefilter/mimedecode stuff is a distraction IMO, and not really > relevant to the TMDA integration. True, but its a common question and desire. MIME or other message filtering is a common question on -users, coming very close in with "wanted GID" and "how do I do an announcement list". Integrating TMDA really isn't that hard a question or problem. I was interested in integrating TMDA in a fashion that also leant itself to integrating other useful tools, rather than making such further extensions difficult. As such I tried to build a framework more than a single point solution. > * If we can find a way to do this without procmail, that's a bonus. That would be fairly easy under Exim -- you can do all the extra work between the director and transport. > That said, thanks for writing this up. I think it's a good start, and > longer overdue. >> Getting the filter process to execute as 'list' under postfix proved >> a bitch. > What user is the filter process executed as by default? nobody.nogroup. -- 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 claw@kanga.nu Wed Jul 31 19:28:30 2002 From: claw@kanga.nu (J C Lawrence) Date: Wed, 31 Jul 2002 11:28:30 -0700 Subject: [Mailman-Developers] Initial Mailman v2.0 with TMDA and Mime filtering In-Reply-To: Message from Fil of "Wed, 31 Jul 2002 19:55:44 +0200." <20020731175544.GB25611@rezo.net> References: <1262.1028093412@kanga.nu> <1432.1028094405@kanga.nu> <15687.63160.812836.586134@anthem.wooz.org> <7660.1028136792@kanga.nu> <20020731175544.GB25611@rezo.net> Message-ID: <8350.1028140110@kanga.nu> On Wed, 31 Jul 2002 19:55:44 +0200 fil wrote: >> TMDA then provides a confirmation system for held mail by sending a >> message back to the address that sent the held message, requesting >> confirmation that the poster not only exists, but really meant to >> send that message. The confirmation message contains both >> instructions on how to confirm, and a copy of the original message. > This is really neat, I'm eager to see it in action ASAP. I've sent you details for my test setup off-list. > A simple question though: does TMDA read the "language" data of the > mailman list, and does/can it send the confirmation message in that > language (when available)? Or are we going to have to wait for a > fuller integration to enjoy this in i18n? No. However you can rewrite the templates and other message portions that go to forming the confirmation requests etc in whatever language you want. In this way you make TMDA agree with however you've localised Mailman. With a little extra work in the procmailrc you can even have this work across multiple lists each with a different language preference pointing at different TMDA templates etc. -- 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 noreply@sourceforge.net Wed Jul 31 19:35:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jul 2002 11:35:37 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-589284 ] Ambiguous user preference Message-ID: Bugs item #589284, was opened at 2002-07-31 11:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589284&group_id=103 Category: documentation Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Nick Arnett (narnett) Assigned to: Nobody/Anonymous (nobody) Summary: Ambiguous user preference Initial Comment: (2.1b2) The heading and text for users to choose whether or not their address is visible are at odds with each other. One or the other needs its logic reversed, else users won't know whether "yes" means their address is concealed or visible, etc. -- Conceal yourself from subscriber list? When someone views the list membership, your email address is normally shown (in an obscured fashion to thwart spam harvesters). If you do not want your email address to show up on this membership roster, select No for this option. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589284&group_id=103 From noreply@sourceforge.net Wed Jul 31 19:39:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jul 2002 11:39:56 -0700 Subject: [Mailman-Developers] [ mailman-Patches-573508 ] ToUsenet: subject prefix stripping Message-ID: Patches item #573508, was opened at 2002-06-25 02:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=573508&group_id=103 Category: mail delivery Group: Mailman 2.0.x >Status: Closed Resolution: None Priority: 5 Submitted By: Mark Weaver (mdw21) Assigned to: Nobody/Anonymous (nobody) Summary: ToUsenet: subject prefix stripping Initial Comment: For some inexplicable reason ToUsenet is trying to -add- the subject prefix. Now this doesn't work generally anyway (consider a plain post - this won't do it). Typically, the subject prefix is the list- name, which just replicates information we already have (as we already know which newsgroup we are looking at). Anyway, arguments aside, I've fixed up ToUsenet.py to go the other way and remove subjects. (I would have made this an option, but my Python is non-existent). ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-31 14:39 Message: Logged In: YES user_id=12800 I've added something to MM2.1b3 to selectively disable subject munging for usenet gatewayed posts. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-31 13:01 Message: Logged In: YES user_id=12800 This patch is only relevant to MM2.0, and that version is in critical bug fix phase only. MM2.1 does it differently, but I'm wondering if the subject should not be added to news bound messages either? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=573508&group_id=103 From claw@kanga.nu Wed Jul 31 19:40:11 2002 From: claw@kanga.nu (J C Lawrence) Date: Wed, 31 Jul 2002 11:40:11 -0700 Subject: [Mailman-Developers] Re: Initial Mailman v2.0 with TMDA and Mime filtering In-Reply-To: Message from J C Lawrence of "Wed, 31 Jul 2002 11:25:28 PDT." <8260.1028139928@kanga.nu> References: <25772.2319839106$1028093506@news.gmane.org> <8260.1028139928@kanga.nu> Message-ID: <8528.1028140811@kanga.nu> On Wed, 31 Jul 2002 11:25:28 -0700 J C Lawrence wrote: > That would be fairly easy under Exim -- you can do all the extra work > between the director and transport. Note: The edits made to exim.conf in my HOW-TO are a simple merge set of the edits required by Mailman's README.Exim and TMDA's. I don't add anything new to the picture there. -- 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 JasonR.Mastaler Wed Jul 31 20:17:14 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Wed, 31 Jul 2002 13:17:14 -0600 Subject: [Mailman-Developers] Re: Initial Mailman v2.0 with TMDA and Mime filtering References: <25772.2319839106$1028093506@news.gmane.org> <8260.1028139928@kanga.nu> <8528.1028140811@kanga.nu> Message-ID: J C Lawrence writes: > The edits made to exim.conf in my HOW-TO are a simple merge set of > the edits required by Mailman's README.Exim and TMDA's. I don't > add anything new to the picture there. I didn't realize this, thanks. -- (http://tmda.net/) From noreply@sourceforge.net Wed Jul 31 20:31:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jul 2002 12:31:21 -0700 Subject: [Mailman-Developers] [ mailman-Patches-573503 ] message-id munge error in ToUsenet.py Message-ID: Patches item #573503, was opened at 2002-06-25 01:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=573503&group_id=103 Category: None >Group: Mailman 2.0.x >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Mark Weaver (mdw21) Assigned to: Nobody/Anonymous (nobody) Summary: message-id munge error in ToUsenet.py Initial Comment: # Our Message-ID format is msgid = msg.get('message-id') hackmsgid = 1 if msgid: mo = re.search( msgid, r'[^@]+)@(?P[^>]+)>') in the re.search, the parameters are the wrong way around. The consequence is that a new message-id is assigned to each message and threading is easily broken. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-31 15:31 Message: Logged In: YES user_id=12800 Thanks fixed in MM2.0.x cvs. It'll be part of MM2.0.14 if there ever is one. Patch not relevant for MM2.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=573503&group_id=103 From JasonR.Mastaler Wed Jul 31 20:16:30 2002 From: JasonR.Mastaler (JasonR.Mastaler) Date: Wed, 31 Jul 2002 13:16:30 -0600 Subject: [Mailman-Developers] Re: Initial Mailman v2.0 with TMDA and Mime filtering References: <25772.2319839106$1028093506@news.gmane.org> <8260.1028139928@kanga.nu> Message-ID: J C Lawrence writes: > Given that the alias filter has to execute as a specific effective > UID/GID any HOW-TO is necessarily going to be MTA specific. There > is no agreement or common standard among MTAs for configuring that. Yup. Postfix should have a dot-qmail-like interface soon, so at least Postfix and qmail will no longer have this dilemma. > Integrating TMDA really isn't that hard a question or problem. To us sure, but you'd be astonished how few people have gotten it to work under non-qmail -- or more to the point, how many have tried and then given up. > I was interested in integrating TMDA in a fashion that also leant > itself to integrating other useful tools, rather than making such > further extensions difficult. As such I tried to build a framework > more than a single point solution. I understand. It's just when I started reading through your 28K HOWTO, my head started spinning. Perhaps this is just because I don't use Exim and procmail though. >> What user is the filter process executed as by default? > > nobody.nogroup. How about adding `mailman' to nobody's supplemental groups list so it can read ~mailman's files? -- (http://tmda.net/) From laurence@digitalpulp.com Wed Jul 31 21:06:41 2002 From: laurence@digitalpulp.com (Laurence Berland) Date: Wed, 31 Jul 2002 16:06:41 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] Adding exception to html-stripping in the archive In-Reply-To: <200207311204.01789.laurence@digitalpulp.com> References: <200207311204.01789.laurence@digitalpulp.com> Message-ID: <200207311606.41289.laurence@digitalpulp.com> begin quote from Laurence Berland on Wednesday 31 July 2002 12:04 pm > I've already written code that filters the messages on their way to the > archiver, substituting based on regular expressions. It does this in t= he > Queue/ArchRunner.py file, in just about the last spot before the actual > archiver gets called. It can't go in the archiver, because it needs to= be > able to read the mlist variable for configuration and such. I need to = be > able to use a regular expression to substitute in a snippet of html cod= e. > This could be used for several things, but my intention is to use it to= add > an img tag. Is there a way to configurably get around the html-sanitiz= ing > done by the archiver in some non-kludge way? I'm not sure if anyone is reading these, though I tend to suspect not. I= n any=20 case, I've found the kludge way to go about doing this, but it's really q= uite=20 awful. I changed the websafe function in utils.py to just return the ver= y=20 string it is passed. Please tell me there's a better way, as this requir= es a=20 recompile to change, and it's not something I even want done for every li= st. =20 If there isn't a better way yet, can anyone think of how to code one? My= =20 biggest problem is the lack of an mlist object near many websafe calls,=20 meaning I can't readily grab config variables for a list. > > TIA, > Laurence > From noreply@sourceforge.net Wed Jul 31 21:09:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jul 2002 13:09:13 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-589284 ] Ambiguous user preference Message-ID: Bugs item #589284, was opened at 2002-07-31 14:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589284&group_id=103 >Category: Web/CGI Group: 2.1 beta >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Nick Arnett (narnett) Assigned to: Nobody/Anonymous (nobody) Summary: Ambiguous user preference Initial Comment: (2.1b2) The heading and text for users to choose whether or not their address is visible are at odds with each other. One or the other needs its logic reversed, else users won't know whether "yes" means their address is concealed or visible, etc. -- Conceal yourself from subscriber list? When someone views the list membership, your email address is normally shown (in an obscured fashion to thwart spam harvesters). If you do not want your email address to show up on this membership roster, select No for this option. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-31 16:09 Message: Logged In: YES user_id=12800 Fixed in cvs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589284&group_id=103 From noreply@sourceforge.net Wed Jul 31 21:11:25 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jul 2002 13:11:25 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-588373 ] bug with 2.1b2 (something with cookies?) Message-ID: Bugs item #588373, was opened at 2002-07-30 00:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=588373&group_id=103 Category: None >Group: 2.1 beta >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Paul Marshall (paulmarshll) Assigned to: Nobody/Anonymous (nobody) Summary: bug with 2.1b2 (something with cookies?) Initial Comment: This is hopefully my third and final stupid question involving mailman. I have mailman 2.1b2 setup and mostly working (I can create lists, and post, etc...). However whenever I try to log into a list via the admin page to edit/delete/whatever to it, it comes up with this bug: Traceback (most recent call last): File "/var/mailman/scripts/driver", line 82, in run_main main() File "/var/mailman/Mailman/Cgi/admin.py", line 82, in main cgidata.getvalue('adminpw', '')): File "/var/mailman/Mailman/SecurityManager.py", line 208, in WebAuthenticate print self.MakeCookie(ac, user) File "/var/mailman/Mailman/SecurityManager.py", line 223, in MakeCookie c = Cookie.SimpleCookie() AttributeError: 'module' object has no attribute 'SimpleCookie' Is this a permissions problem? something to do with creating cookies...Honestly, I have no idea... I've searched some bug databases and most likely passed right over it, however I can't seem to find anything dealing with this error. Thanks for all the help. Paul ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-31 16:11 Message: Logged In: YES user_id=12800 Weird! The update script should have gotten rid of those files automatically. It's probably too late for your installation, but if not, try running "bin/update -f" manually and see if the Cookie.pyc file sticks around. ---------------------------------------------------------------------- Comment By: Paul Marshall (paulmarshll) Date: 2002-07-31 12:43 Message: Logged In: YES user_id=582441 I fixed the problem. Apparently I still had Cookie.py and Cookie.pyc, which I deleted, this seemed to fix the problem. Found this on: http://mail.python.org/pipermail-21/mailman-developers/2001- November/010020.html Thanks anyways. This post can be deleted. Paul ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=588373&group_id=103 From noreply@sourceforge.net Wed Jul 31 21:12:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jul 2002 13:12:30 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-585484 ] virtual domain lists misdirect autoreply Message-ID: Bugs item #585484, was opened at 2002-07-23 12:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585484&group_id=103 Category: bounce detection Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: Byron T. Watts (btwatts) Assigned to: Nobody/Anonymous (nobody) Summary: virtual domain lists misdirect autoreply Initial Comment: Using mailman with virtual domain hosting. Bounced messages for a particular list are going to the wrong list administrator (not even on the same domain). The particular notices that I'm seeing misdirected, are the useridi> is on vacation messages. I am not certain whether other messages are being similarly misdirected. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-31 16:12 Message: Logged In: YES user_id=12800 Moving this to status Pending, for lack of more information. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-24 11:25 Message: Logged In: YES user_id=12800 Sorry, I'll need more information here. Start with the basics: what OS, what MTA, what version of Python, what version of Mailman. How do you have your MTA configured? Have you set up virtual domain support in Mailman properly (differs depending on the version of Mailman you're using). Please include version numbers for all related software. Also if you can provide a reproducible recipe for seeing the bug, or at least attach copies of misdirected messages, these things would help. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=585484&group_id=103 From noreply@sourceforge.net Wed Jul 31 21:20:59 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jul 2002 13:20:59 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-565808 ] Broken options in Hungarian listinfo Message-ID: Bugs item #565808, was opened at 2002-06-07 09:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=565808&group_id=103 Category: Web/CGI Group: 2.1 beta >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: szabolcs szigeti (szigi) Assigned to: Nobody/Anonymous (nobody) Summary: Broken options in Hungarian listinfo Initial Comment: Teh Hungarian template for listinfo is broken, instead of setting options, users are taken to subscription. Similar to bug [ 553033 ] "subscribing via web does not work" This should correct it: *** templates/hu/listinfo.html.orig Fri Jun 7 15:10:36 2002 --- templates/hu/listinfo.html Fri Jun 7 15:08:56 2002 *************** *** 127,133 ****

      ! --- 127,133 ----

      ! ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-31 16:20 Message: Logged In: YES user_id=12800 Fixed, thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=565808&group_id=103 From noreply@sourceforge.net Wed Jul 31 21:21:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jul 2002 13:21:24 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-553033 ] subscribing via web does not work Message-ID: Bugs item #553033, was opened at 2002-05-06 17:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=553033&group_id=103 Category: Web/CGI Group: 2.1 beta >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: javier wilson (javierwilson) Assigned to: Nobody/Anonymous (nobody) Summary: subscribing via web does not work Initial Comment: Users trying to subscribe via web were redirected to the options web page. This only happened with users using Spanish templates. The problem seems to be in the spanish template listinfo.html Instead of "" it should say: "". Is this correct? javier wilson ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-31 16:21 Message: Logged In: YES user_id=12800 I believe this has since been fixed. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-05-06 22:57 Message: Logged In: YES user_id=12800 Yes, but someone who speaks Spanish is going to have to update the es/listinfo.html file. I took a quick look and couldn't tell for sure what should be changed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=553033&group_id=103 From claw@kanga.nu Wed Jul 31 21:43:53 2002 From: claw@kanga.nu (J C Lawrence) Date: Wed, 31 Jul 2002 13:43:53 -0700 Subject: [Mailman-Developers] Re: Initial Mailman v2.0 with TMDA and Mime filtering In-Reply-To: Message from Jason R. Mastaler of "Wed, 31 Jul 2002 13:16:30 MDT." References: <25772.2319839106$1028093506@news.gmane.org> <8260.1028139928@kanga.nu> Message-ID: <10158.1028148233@kanga.nu> On Wed, 31 Jul 2002 13:16:30 -0600 Jason R Mastaler wrote: > J C Lawrence writes: >> Integrating TMDA really isn't that hard a question or problem. > To us sure, but you'd be astonished how few people have gotten it to > work under non-qmail -- or more to the point, how many have tried and > then given up. Given the effective UID etc problem, I can believe. If I hadn't already known how easy it would be to use Exim I might have given up as well (or hand-patched procmail to do what I wanted ala /etc/procmailrcs). >> I was interested in integrating TMDA in a fashion that also leant >> itself to integrating other useful tools, rather than making such >> further extensions difficult. As such I tried to build a framework >> more than a single point solution. > I understand. It's just when I started reading through your 28K > HOWTO, my head started spinning. Perhaps this is just because I don't > use Exim and procmail though. I'm afraid I do all sorts of things with procmail. $ wc -l .~/procmailrc ~/Mail/*.procmail | tail -1 1215 total >>> What user is the filter process executed as by default? >> nobody.nogroup. > How about adding `mailman' to nobody's supplemental groups list so it > can read ~mailman's files? Many other services and processes execute in nobody.nogroup as a known-safe near jail. I'm very unwilling to alter my security stance by extending the permission set of nobody.nogroup, especially when all those email addresses are within the risk set. -- 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 bob@nleaudio.com Wed Jul 31 22:21:11 2002 From: bob@nleaudio.com (Bob Puff@NLE) Date: Wed, 31 Jul 2002 17:21:11 -0400 Subject: [Mailman-Developers] Modifying a header in Procmail References: <25772.2319839106$1028093506@news.gmane.org> <8260.1028139928@kanga.nu> <10158.1028148233@kanga.nu> Message-ID: <3D4854C7.DEE2EB57@nleaudio.com> Hey gang, I need to remove a "Delivered-To:" header within a .procmailrc file. Any pointers? Bob From claw@kanga.nu Wed Jul 31 21:47:29 2002 From: claw@kanga.nu (J C Lawrence) Date: Wed, 31 Jul 2002 13:47:29 -0700 Subject: [Mailman-Developers] TMDA in front of mailman-users with no check against thesubscriber list Message-ID: <10369.1028148449@kanga.nu> Another possible use for TMDA: The rate of FAQ questions on mailman-users is high, damn near the majority of the posts. How about setting up TMDA in front of mailman-users with a confirm request text that explicitly asks, HAVE YOU CHECKED THE FAQ AT ? Repeat posters wouldn't be affected. Then again repeat posters usually don't ask FAQs. -- 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 fil@rezo.net Wed Jul 31 22:10:58 2002 From: fil@rezo.net (Fil) Date: Wed, 31 Jul 2002 23:10:58 +0200 Subject: [Mailman-Developers] TMDA in front of mailman-users with no check against thesubscriber list In-Reply-To: <10369.1028148449@kanga.nu> References: <10369.1028148449@kanga.nu> Message-ID: <20020731211058.GG3390@rezo.net> @ J C Lawrence : > Another possible use for TMDA: > The rate of FAQ questions on mailman-users is high, damn near the > majority of the posts. How about setting up TMDA in front of > mailman-users with a confirm request text that explicitly asks, HAVE > YOU CHECKED THE FAQ AT ? No! Be very very friendly to anyone coming to you. You can bite afterwards, but only if they have harrassed you. I'm copying here the comments I just sent you after testing TMDA-Mailman on your system (thanks!) - hope you don'"t mind my copying part of your answer. > > Fil : Otherwise this message looks quite a lot like a "mailer-daemon" > > message, and most people will discard it. Maybe that's wanted ;) > > JC Lawrence: Hehn. true. I'm working on the wording to be a bit more > friendly. Yes. By very definition this message is for newcomers: be very friendly, very clear about your intents, and very very clear about what they should do. Let's try: """ You have just sent a message to

      - it has been temporariliy blocked. Please answer to this email to allow your posting to get through to the list (or list moderators). Thank you. * * * Short explanation : in order to fight SPAM (unsollicited mail), we (kanga.nu) have decided that the first time someone posts a message to the mailing-list system, we would write back in order to confirm that it's a real person, not a spammer. Once you have replied to this email, your address will be known to us; you'll never have to repeat this procedure. A longer explanation can be found on our website at http://wwwwwwww with links describing : what is spam, how to fight it, and so on. If you wish to contact a human about this system, please write to (This message has been sent by a computer without human intervention.) """ Having gone through all of the process, I've received 3 messages from the system : 1) please reply 2) confirmed : you have replied 3) your message awaitrs moderator approval I think step 2) is unnecessary in a mailing-list context. -- Fil From chuqui@plaidworks.com Wed Jul 31 22:22:58 2002 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Wed, 31 Jul 2002 14:22:58 -0700 Subject: [Mailman-Developers] TMDA in front of mailman-users with no check against thesubscriber list In-Reply-To: <20020731211058.GG3390@rezo.net> Message-ID: On 7/31/02 2:10 PM, "Fil" wrote: > @ J C Lawrence : >> mailman-users with a confirm request text that explicitly asks, HAVE >> YOU CHECKED THE FAQ AT ? > > No! Be very very friendly to anyone coming to you. You can bite afterwards, > but only if they have harrassed you. Even simpler. This is a classic example of open-source-helper-burnout. Yes, the same questions show up over and ove.r yes, they're in the FAQ. When you start getting frustrated at this, remember that you are not the only person on the list willing and able to answer questions. So don't yell at the poor person asking the question. Shut up and stop worrying about it. Someone else will pick up the ball and take a shift in helping the newbies get what they need. Think of it as tag-team tech support. Answer what you feel like naswering, don't answer what bothers you, and others will do the same. And funny enough, if you do, it all works out and nobody gets yelled at. Even better, you never get so stressed out you say the hell with it forever. Me, I used to think *I* had to answer stuff. I found out (the hard way) that if I didn't, magically the world didn't fall apart. In reality, it wasn't ME that was the key there, but US. Except, of course, to my ego... Once I realized that, I found stuff got a lot less stressful, and enjoyable. And stuff still happened. Magic. -- Chuq Von Rospach, Architech chuqui@plaidworks.com -- http://www.chuqui.com/ Someday, we'll look back on this, laugh nervously and change the subject. From claw@kanga.nu Wed Jul 31 22:26:45 2002 From: claw@kanga.nu (J C Lawrence) Date: Wed, 31 Jul 2002 14:26:45 -0700 Subject: [Mailman-Developers] Modifying a header in Procmail In-Reply-To: Message from "Bob Puff@NLE" of "Wed, 31 Jul 2002 17:21:11 EDT." <3D4854C7.DEE2EB57@nleaudio.com> References: <25772.2319839106$1028093506@news.gmane.org> <8260.1028139928@kanga.nu> <10158.1028148233@kanga.nu> <3D4854C7.DEE2EB57@nleaudio.com> Message-ID: <11493.1028150805@kanga.nu> On Wed, 31 Jul 2002 17:21:11 -0400 bob > wrote: > Hey gang, I need to remove a "Delivered-To:" header within a > .procmailrc file. Any pointers? man formail. -- 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 noreply@sourceforge.net Wed Jul 31 22:42:50 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jul 2002 14:42:50 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-589387 ] can user@host.com = user@abc.host.com? Message-ID: Bugs item #589387, was opened at 2002-07-31 16:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589387&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Marshall (paulmarshll) Assigned to: Nobody/Anonymous (nobody) Summary: can user@host.com = user@abc.host.com? Initial Comment: I have people who subscribe under user@host.com however, their email is identified as user@abc.host.com. When Mailman sees this it rejects the post claiming that user@abc.host.com isn't subscribed to the list. This problem is very similar to the one listed here: http://mail.python.org/pipermail/mailman-users/2002- July/021343.html I tried the solution that the person suggested, modifying SMART_ADDRESS_MATCH =3D 1 in mm_cfg.py, however this still didn't work. I tried it with it set as: SMART_ADDRESS_MATCH = 1 SMART_ADDRESS_MATCH =3D 1 SMART_ADDRESS_MATCH = 0 Although none of these worked, I am assuming it has to be set to true (1). Anyone have any ideas on why that isn't working or whatelse I may need to do? Thanks. Paul ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=589387&group_id=103 From noreply@sourceforge.net Wed Jul 31 23:06:39 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jul 2002 15:06:39 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-573071 ] nonmembers can post after upgrading Message-ID: Bugs item #573071, was opened at 2002-06-24 07:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=573071&group_id=103 Category: security/privacy Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Daniel Buchmann (avalon) Assigned to: Nobody/Anonymous (nobody) Summary: nonmembers can post after upgrading Initial Comment: After upgrading to current CVS (2.1b2+), nonmembers are now allowed to post to a list that used to be members-only (in MM 2.0.11). The member_posting_only config variable is not propagated to the generic_nonmember_action variable when upgrading. This caused me a lot of trouble... :) The fix is probably trivial, but my lack of python experience prevents me from submitting a patch... ;) ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-31 18:06 Message: Logged In: YES user_id=12800 Actually, I'm sure the fix is anything /but/ trivial since the semantics and interaction of the MM2.0.x member_posting_only, posters, and moderated attributes is simply too confusing. I'm not sure I got it right the first time, and I'm not even sure that my current thinking on the subject is correct. Here is my current thinking about the steps needed to do an upgrade. I'd love to have someone else sanity check this, but I'll understand if no one does or can. We're not going to "fix" 2.1b2 lists, but this might fix things for lists that are upgraded from 2.0.x to 2.1b3. None of this is tested yet -- or even implemented -- since I need to think on it some more and see if this is correct. Have any comments? Oh yeah. I need to put a nice big warning in the UPGRADING file. # Now convert what we can... Note that the interaction between the # MM2.0.x attributes `moderated', `member_posting_only', and `posters' is # so confusing, it makes my brain really ache. Which is why they go away # in MM2.1. I think the best we can do semantically is the following: # # - If moderated == yes, then any sender who's address is not on the # posters attribute would get held for approval. if the sender was on # the posters list, then we'd defer judgement to a later step # - If member_posting_only == yes, then members could post without holds, # and if there were any addresses added to posters, they could also post # without holds. # - If member_posting_only == no, then what happens depends on the value # of the posters attribute: # o If posters was empty, then anybody can post without their # message being held for approval # o If posters was non-empty, then /only/ those addresses could post # without approval, i.e. members not on posters would have their # messages held for approval. # # How to translate this mess to MM2.1 values? I'm sure I got this wrong # before, but here's how we're going to do it, as of MM2.1b3. # # - We'll control member moderation through their Moderate flag, and # non-member moderation through the generic_nonmember_action, # hold_these_nonmembers, and accept_these_nonmembers. # - If moderated == yes then we need to troll through the addresses on # posters, and any non-members would get added to # accept_these_nonmembers. /Then/ we need to troll through the # membership and any member not on posters would get their Moderate flag # set. Then generic_nonmember_action gets set to 1 (hold) so nonmembers # get moderated, and default_member_moderation will be set to 1 (hold) # so new members will also get held for moderation. We'll stop here. # - We only get to here if moderated == no. # - If member_posting_only == yes, then we'll also set # generic_nonmember_action to 1 and we'll turn off the Moderate flag for # members. Then we troll through the posters attribute and add all # those addresses to accept_these_nonmembers. We'll stop here. # - We only get to here if member_posting_only == no # - If posters is empty, then anybody could post without being held for # approval, so we'll set generic_nonmember_action to 0 (accept), and # we'll turn off the Moderate flag for all members. We'll also turn off # default_member_moderation so new members can post without approval. # We'll stop here. # - We only get here if posters is non-empty. # - This means that /only/ the addresses on posters got to post without # being held for approval. So first, we troll through posters and add # all non-members to accept_these_nonmembers. Then we troll through the # membership and if their address is on posters, we'll clear their # Moderate flag, otherwise we'll set it. We'll turn on # default_member_moderation so new members get moderated. We'll set # generic_nonmember_action to 1 (hold) so all other non-members will get # moderated. And I think we're finally done. # # SIGH. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=573071&group_id=103 From noreply@sourceforge.net Wed Jul 31 23:08:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 31 Jul 2002 15:08:54 -0700 Subject: [Mailman-Developers] [ mailman-Bugs-573071 ] nonmembers can post after upgrading Message-ID: Bugs item #573071, was opened at 2002-06-24 07:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=573071&group_id=103 Category: security/privacy Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Daniel Buchmann (avalon) Assigned to: Nobody/Anonymous (nobody) Summary: nonmembers can post after upgrading Initial Comment: After upgrading to current CVS (2.1b2+), nonmembers are now allowed to post to a list that used to be members-only (in MM 2.0.11). The member_posting_only config variable is not propagated to the generic_nonmember_action variable when upgrading. This caused me a lot of trouble... :) The fix is probably trivial, but my lack of python experience prevents me from submitting a patch... ;) ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-31 18:08 Message: Logged In: YES user_id=12800 Ugh, that last comment looks horrible. I'm attaching the plain text to this followup. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-31 18:06 Message: Logged In: YES user_id=12800 Actually, I'm sure the fix is anything /but/ trivial since the semantics and interaction of the MM2.0.x member_posting_only, posters, and moderated attributes is simply too confusing. I'm not sure I got it right the first time, and I'm not even sure that my current thinking on the subject is correct. Here is my current thinking about the steps needed to do an upgrade. I'd love to have someone else sanity check this, but I'll understand if no one does or can. We're not going to "fix" 2.1b2 lists, but this might fix things for lists that are upgraded from 2.0.x to 2.1b3. None of this is tested yet -- or even implemented -- since I need to think on it some more and see if this is correct. Have any comments? Oh yeah. I need to put a nice big warning in the UPGRADING file. # Now convert what we can... Note that the interaction between the # MM2.0.x attributes `moderated', `member_posting_only', and `posters' is # so confusing, it makes my brain really ache. Which is why they go away # in MM2.1. I think the best we can do semantically is the following: # # - If moderated == yes, then any sender who's address is not on the # posters attribute would get held for approval. if the sender was on # the posters list, then we'd defer judgement to a later step # - If member_posting_only == yes, then members could post without holds, # and if there were any addresses added to posters, they could also post # without holds. # - If member_posting_only == no, then what happens depends on the value # of the posters attribute: # o If posters was empty, then anybody can post without their # message being held for approval # o If posters was non-empty, then /only/ those addresses could post # without approval, i.e. members not on posters would have their # messages held for approval. # # How to translate this mess to MM2.1 values? I'm sure I got this wrong # before, but here's how we're going to do it, as of MM2.1b3. # # - We'll control member moderation through their Moderate flag, and # non-member moderation through the generic_nonmember_action, # hold_these_nonmembers, and accept_these_nonmembers. # - If moderated == yes then we need to troll through the addresses on # posters, and any non-members would get added to # accept_these_nonmembers. /Then/ we need to troll through the # membership and any member not on posters would get their Moderate flag # set. Then generic_nonmember_action gets set to 1 (hold) so nonmembers # get moderated, and default_member_moderation will be set to 1 (hold) # so new members will also get held for moderation. We'll stop here. # - We only get to here if moderated == no. # - If member_posting_only == yes, then we'll also set # generic_nonmember_action to 1 and we'll turn off the Moderate flag for # members. Then we troll through the posters attribute and add all # those addresses to accept_these_nonmembers. We'll stop here. # - We only get to here if member_posting_only == no # - If posters is empty, then anybody could post without being held for # approval, so we'll set generic_nonmember_action to 0 (accept), and # we'll turn off the Moderate flag for all members. We'll also turn off # default_member_moderation so new members can post without approval. # We'll stop here. # - We only get here if posters is non-empty. # - This means that /only/ the addresses on posters got to post without # being held for approval. So first, we troll through posters and add # all non-members to accept_these_nonmembers. Then we troll through the # membership and if their address is on posters, we'll clear their # Moderate flag, otherwise we'll set it. We'll turn on # default_member_moderation so new members get moderated. We'll set # generic_nonmember_action to 1 (hold) so all other non-members will get # moderated. And I think we're finally done. # # SIGH. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=573071&group_id=103