From scott-brown@home.com Wed Aug 1 00:47:12 2001 From: scott-brown@home.com (Scott Brown) Date: Tue, 31 Jul 2001 19:47:12 -0400 Subject: [Mailman-Developers] Clean output with bin/withlist?? Message-ID: <003b01c11a1b$1f2bfc20$0401a8c0@ibmpeers> How do I __cleanly__ get the "prefered domain" that is associated with a given list? I'm sure this is possible with the "withlist"... and it's the "host_name" attribute I want (isnt it??) .... which if I understand the docs is a member of the "m" collection (is that the right name under Python??) My question is how do I actually extract that (preferably as a one liner without a pile of other output, such that I can pull it into a perl script and use it without a lot of additional processing) My first attempt was [root@apollo /home/mailman]# echo "m.host_name" | python -i /home/mailman/bin/withlist test2 Loading list: test2 (unlocked) >>> 'apollo.host-ops.com' >>> Finalizing [root@apollo /home/mailman]# But there's all that other crap that I'd prefer not to get, so that I dont have to parse it out.... Anyone got any ideas?? From jarrell@vt.edu Wed Aug 1 00:58:05 2001 From: jarrell@vt.edu (Ron Jarrell) Date: Tue, 31 Jul 2001 19:58:05 -0400 Subject: [Mailman-Developers] Clean output with bin/withlist?? In-Reply-To: <003b01c11a1b$1f2bfc20$0401a8c0@ibmpeers> Message-ID: <5.1.0.14.2.20010731195610.043395f0@lennier.cc.vt.edu> At 07:47 PM 7/31/01 -0400, Scott Brown wrote: >How do I __cleanly__ get the "prefered domain" that is associated with a >given list? > >I'm sure this is possible with the "withlist"... and it's the "host_name" >attribute I want (isnt it??) .... which if I understand the docs is a >member of the "m" collection (is that the right name under Python??) > >My question is how do I actually extract that (preferably as a one liner >without a pile of other output, such that I can pull it into a perl script >and use it without a lot of additional processing) Well, the simple answer, that I'm sure Barry will happily espouse, is to do your script in python instead, and just read the variable directly :-). However, the brute force method is just take withlist, and hack it slightly to just be a dedicated program that just prints the variable you're looking for. From scott-brown@home.com Wed Aug 1 01:46:19 2001 From: scott-brown@home.com (Scott Brown) Date: Tue, 31 Jul 2001 20:46:19 -0400 Subject: [Mailman-Developers] Clean output with bin/withlist?? In-Reply-To: <5.1.0.14.2.20010731195610.043395f0@lennier.cc.vt.edu> Message-ID: <000201c11a23$616e9860$0401a8c0@ibmpeers> > Well, the simple answer, that I'm sure Barry will happily > espouse, is to do your script in python instead, and just > read the variable directly :-). I'd prefer to limit the number of new languages I try to pick up at the same time..... at work we're making the jump from COBOL-68 on a mainframe up to C++/VB on PCs..... so I've got plenty on the go right now :)) > However, the brute force method is just take withlist, and hack it > slightly to just be a dedicated program that just prints the variable > you're looking for. Now that's just messy... duplicating code for no good reason.... Maybe a little developer pressure on Barry for a -q(uiet) flag is in order?? With 2.1 soon to be released (nudge nudge) maybe it's still within the timeframe for producing this wee little change... (otherwise I'll have to try to hack a quiet flag in there... maybe... if I'm lucky :) From alaric@babcom.com Wed Aug 1 01:50:53 2001 From: alaric@babcom.com (Phil Stracchino) Date: Tue, 31 Jul 2001 17:50:53 -0700 Subject: [Mailman-Developers] Clean output with bin/withlist?? In-Reply-To: <003b01c11a1b$1f2bfc20$0401a8c0@ibmpeers>; from scott-brown@home.com on Tue, Jul 31, 2001 at 07:47:12PM -0400 References: <003b01c11a1b$1f2bfc20$0401a8c0@ibmpeers> Message-ID: <20010731175053.A8868@babylon5.babcom.com> On Tue, Jul 31, 2001 at 07:47:12PM -0400, Scott Brown wrote: > My first attempt was > > [root@apollo /home/mailman]# echo "m.host_name" | python -i > /home/mailman/bin/withlist test2 > Loading list: test2 (unlocked) > >>> 'apollo.host-ops.com' > >>> > Finalizing > [root@apollo /home/mailman]# > > But there's all that other crap that I'd prefer not to get, so that I dont > have to parse it out.... > > Anyone got any ideas?? Assuming the format of that output is consistent, try this in your perl script: ($pref_host = `echo "m.host_name" | python -i`[2]) =~ s/.*'(.+)'/$1/; -- Linux Now! ..........Because friends don't let friends use Microsoft. phil stracchino -- the renaissance man -- mystic zen biker geek alaric@babcom.com halmayne@sourceforge.net 2000 CBR929RR, 1991 VFR750F3 (foully murdered), 1986 VF500F (sold) From rguerra@rcp.net.pe Wed Aug 1 02:47:55 2001 From: rguerra@rcp.net.pe (Rolando Guerra) Date: Tue, 31 Jul 2001 20:47:55 -0500 (GMT) Subject: [Mailman-Developers] Problems with mailman 2.1a2 Message-ID: Hi, I have installed mailman 2.1a2 in Solaris Intel 8 with Exim 3.31, Python 2.1 and mimelib 0.4. I have two problems: - My error log is growing all the time with the message: --------------------------------------------------------------- Jul 31 20:17:51 2001 (23386) Uncaught runner exception: 'int' object has no attribute 'lower' Jul 31 20:17:51 2001 (23386) Traceback (most recent call last): File "/usr/local/mailman/Mailman/Queue/IncomingRunner.py", line 134, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Handlers/Hold.py", line 127, in process if mlist.administrivia and Utils.is_administrivia(msg): File "/usr/local/mailman/Mailman/Utils.py", line 555, in is_administrivia line = reader.readline() File "/usr/local/lib/python2.1/site-packages/mimelib/MsgReader.py", line 42, in readline self._root = self._payload[self._pos] File "/usr/local/lib/python2.1/site-packages/mimelib/Message.py", line 100, in __getitem__ return self.get(name) File "/usr/local/lib/python2.1/site-packages/mimelib/Message.py", line 159, in get name = name.lower() AttributeError: 'int' object has no attribute 'lower' ---------------------------------------------------------------- - I installed Mailman in /usr/local, but the private archives are linked to the /var partition: private -> /var/mailman/private if I create a new list for example "test", only the directory "test.mbox" is created but no the directory "test" and the list archives never are created. I have checked the rigths and they are OK, but only the directory xxxx.mbox is created. Before, I was working with the same scheme without problems, with Mailmna 2.0.5. Please, somebody can help me? Thanks in advance Rolando From barry@zope.com Wed Aug 1 07:29:38 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 1 Aug 2001 02:29:38 -0400 Subject: [Mailman-Developers] Clean output with bin/withlist?? References: <003b01c11a1b$1f2bfc20$0401a8c0@ibmpeers> Message-ID: <15207.41426.271446.112394@anthem.wooz.org> >>>>> "SB" == Scott Brown writes: SB> How do I __cleanly__ get the "prefered domain" that is SB> associated with a given list? SB> I'm sure this is possible with the "withlist"... and it's the SB> "host_name" attribute I want (isnt it??) Correct. SB> .... which if I understand the docs is a member of the "m" SB> collection (is that the right name under Python??) To be pedantic :) "m" is a module global variable bound to an instance of the MailList class. Or simpler: "m" is a mailing list object. SB> My question is how do I actually extract that (preferably as a SB> one liner without a pile of other output, such that I can pull SB> it into a perl script and use it without a lot of additional SB> processing) Put this in $prefix/bin/hostname.py: -------------------- snip snip -------------------- def hostname(m): print m.host_name -------------------- snip snip -------------------- and run with % bin/withlist -q -r hostname mylist wooz.org The Perl goo is up to you! Of course... SB> With 2.1 soon to be released (nudge nudge) maybe it's still SB> within the timeframe for producing this wee little SB> change... (otherwise I'll have to try to hack a quiet flag in SB> there... maybe... if I'm lucky :) ...you're lucky I'm feeling insomniatic today. -q is a good idea, easy to add, and checked into cvs two minutes from now. :) -Barry From jaccino@ieev.uma.es Wed Aug 1 12:56:14 2001 From: jaccino@ieev.uma.es (Jose A. Accino) Date: Wed, 1 Aug 2001 13:56:14 +0200 Subject: [Mailman-Developers] Memberships reminder problem on 2.1a2 Message-ID: I have just received the monthly reminders from the lists I'm susbcribed on our Mailman server (running 2.1.a2). However, they all have the same X- or List- headers, as if they were coming from the same 'test' list (see below), that is, the list shown on the headers is not the same list the reminder refers on the body. Is this a bug or am I missing something? Regards, JA. ------------------------------------------------------------- Sender: test-admin@our.list.server X-BeenThere: test@our.list.server X-Mailman-Version: 2.1a3 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: [...] List Password // URL ---- -------- list1@our.list.server zzzzzz http://our.list.server/mailman/options/list1/jaccino%40.our.list.server --------------------------------------------------------------------- Jose Alfonso Accino Universidad de M=E1laga Direcci=F3n de Ense=F1anza Virtual http://www.ieev.uma.es Bulevar Louis Pasteur, 33 - Edif. SCAI Telf.: +34-5-213 29 44 29071 MALAGA (Espa=F1a) Fax: +34-5-213 29 45 =20 From scott-brown@home.com Wed Aug 1 12:52:32 2001 From: scott-brown@home.com (Scott Brown) Date: Wed, 1 Aug 2001 07:52:32 -0400 Subject: [Mailman-Developers] Clean output with bin/withlist?? In-Reply-To: <15207.41426.271446.112394@anthem.wooz.org> Message-ID: <002e01c11a81$1c1ab420$0401a8c0@ibmpeers> > > To be pedantic :) "m" is a module global variable bound to an instance > of the MailList class. Or simpler: "m" is a mailing list object. > Gotcha... > > Put this in $prefix/bin/hostname.py: > > -------------------- snip snip -------------------- > def hostname(m): > print m.host_name > -------------------- snip snip -------------------- > > and run with > > % bin/withlist -q -r hostname mylist > wooz.org > > The Perl goo is up to you! Thanks... I knew it would be simple... I was just attacking it from a "one liner" route.... > Of course... > > SB> With 2.1 soon to be released (nudge nudge) maybe it's still > SB> within the timeframe for producing this wee little > SB> change... (otherwise I'll have to try to hack a quiet flag in > SB> there... maybe... if I'm lucky :) > > ...you're lucky I'm feeling insomniatic today. -q is a good idea, > easy to add, and checked into cvs two minutes from now. :) > Again my thanks.... From kaja@daimi.au.dk Wed Aug 1 14:29:35 2001 From: kaja@daimi.au.dk (Kaja P. Christiansen) Date: Wed, 1 Aug 2001 15:29:35 +0200 Subject: [Mailman-Developers] Looping digest - mailman bug? In-Reply-To: <20010730210641.D20676@xs4all.nl> References: <15205.38107.541898.68781@daimi.au.dk> <20010730210641.D20676@xs4all.nl> Message-ID: <15208.1087.484786.794274@daimi.au.dk> Thomas Wouters writes: > > + bar = re.compile('\n\.') > > + msgtext = re.sub(bar, '\n .', msgtext, 0) > > Sorry, this is the wrong fix. "\n." isn't the pattern that breaks it; you > want "\r?\n.\r?\n". Not really; to be precise, "\n\.\n" is what breaks mail delivery. This was tested and confirmed in mailman lists using Sendmail delivery module, in standard installations of Sendmail 8.11.2 and Postfix 20010228-pl03 and on two different platforms: IRIX 6.5 vs. RedHat 6.2. If a message contains MIME part (text/plain format) with "\n.\n" in it, it triggers the mail bombing. If there is no MIME, the message body is proccessed up to "\n.\.\n", the rest gets truncated. > That's not the issue; IIRC, both the smtplib module (used by the SMTPDirect > delivery in Mailman) as the Sendmail deliverer use CRLF's, adding CR's where > necessary. CRLF's issues notwithstanding, looping digests has given much distress to many list members and the patch above prevents foul behaviour. If there is a better suggestion, I'll be greatful. > My question was whether the message text, at that moment, was guaranteed to > contain CR's (or guaranteed not to contain them.) Guaranteed not to contain CR's; I've saved a few of the 'bombing messages' and the single dot on a line is preceeded and followed by LF's. This said, thanks to the Mailman team for the wonderful software; Mailman has been a great success for mailing lists for which I am responsible (on two different domains); which is the very reason for getting into this... Kaja From thomas@xs4all.net Wed Aug 1 14:52:22 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Wed, 1 Aug 2001 15:52:22 +0200 Subject: [Mailman-Developers] Looping digest - mailman bug? In-Reply-To: <15208.1087.484786.794274@daimi.au.dk> References: <15205.38107.541898.68781@daimi.au.dk> <20010730210641.D20676@xs4all.nl> <15208.1087.484786.794274@daimi.au.dk> Message-ID: <20010801155222.H626@xs4all.nl> On Wed, Aug 01, 2001 at 03:29:35PM +0200, Kaja P. Christiansen wrote: > Thomas Wouters writes: > > > + bar = re.compile('\n\.') > > > + msgtext = re.sub(bar, '\n .', msgtext, 0) > > > > Sorry, this is the wrong fix. "\n." isn't the pattern that breaks it; you > > want "\r?\n.\r?\n". > Not really; to be precise, "\n\.\n" is what breaks mail delivery. Yes. And "\r?\n\.\r?\n" matches that (I forgot to escape the . in my first reply :) Alright, the first '\r?' can be left out, but the second can't. Go ahead and try it; I'm pretty certain "\n.\r\n" will also break off the delivery. > Guaranteed not to contain CR's; I've saved a few of the 'bombing messages' > and the single dot on a line is preceeded and followed by LF's. That is no guarantee, unfortunately. That's empirical proof, which is the most treacherous sort around :) Unless you (or someone else) traced all code paths and see no way for any kind of input to case the message text at that point to contain CR's, I'd prefer to use "\n\.\r?\n", even though that means we have to use the 're' module instead of the 'string' one. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From y.nugroho@student.umist.ac.uk Wed Aug 1 15:51:20 2001 From: y.nugroho@student.umist.ac.uk (Yanuar Nugroho) Date: Wed, 1 Aug 2001 15:51:20 +0100 Subject: [Mailman-Developers] modules relationship References: <15207.42241.672180.698053@anthem.wooz.org> Message-ID: <012e01c11a99$6d3e4340$9baa5882@halls.umist.ac.uk> Dear Barry et al, If I would like to know how the modules are interrelated each other, along with their functionalities in Mailman, what documentation should I consult? Thank you, Yanuar Yanuar Nugroho http://www.yanuar-n.f2s.com/ http://yanuar-nugroho.mainpage.net/ ---------------------------------------- PG. Stud. MSc. Information Systems Engineering, Dept. of Computation, UMIST, Manchester - UK From kaja@daimi.au.dk Wed Aug 1 16:54:19 2001 From: kaja@daimi.au.dk (Kaja P. Christiansen) Date: Wed, 1 Aug 2001 17:54:19 +0200 Subject: [Mailman-Developers] Looping digest - mailman bug? In-Reply-To: <20010801155222.H626@xs4all.nl> References: <15205.38107.541898.68781@daimi.au.dk> <20010730210641.D20676@xs4all.nl> <15208.1087.484786.794274@daimi.au.dk> <20010801155222.H626@xs4all.nl> Message-ID: <15208.9771.971492.187376@daimi.au.dk> Thomas Wouters writes: > Yes. And "\r?\n\.\r?\n" matches that (I forgot to escape the . in my first > reply :) Alright, the first '\r?' can be left out, but the second can't. Go > ahead and try it; I'm pretty certain "\n.\r\n" will also break off the > delivery. Yes, "\n.\r\n" breaks the delivery as well (with unpatched Sendmail.py). > Unless you (or someone else) traced all code > paths and see no way for any kind of input to case the message text at that > point to contain CR's, I'd prefer to use "\n\.\r?\n", Given the alternative, I'd prefer it too :) Kaja From gorg@sun1.imbi.uni-freiburg.de Wed Aug 1 18:22:47 2001 From: gorg@sun1.imbi.uni-freiburg.de (Georg Koch) Date: Wed, 01 Aug 2001 19:22:47 +0200 Subject: [Mailman-Developers] new part for empty header (?) Message-ID: <200108011722.f71HMl605007@sun8.imbi.uni-freiburg.de> Hi Barry, hi Developers, when I look into Mailman/Handlers/Decorate.py, it seems to me that it adds a new header part to a multipart/mixed even if the header is empty. Is it so? Best wishes Georg -- -- Georg Koch ( mailto:gorg@cochrane.de ) | Phone: +49 761 203 6710 German Cochrane Centre | Fax: +49 761 203 6712 Mail: Institute of Medical Biometry and Medical Informatics Stefan-Meier-Strasse 26, D-79104 Freiburg, Germany ...................................................................... Crossing the Quality Chasm: A New Health System for the 21st Century http://www.nap.edu/books/0309072808/html/ From barry@zope.com Wed Aug 1 20:10:48 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 1 Aug 2001 15:10:48 -0400 Subject: [Mailman-Developers] new part for empty header (?) References: <200108011722.f71HMl605007@sun8.imbi.uni-freiburg.de> Message-ID: <15208.21560.252523.226893@anthem.wooz.org> >>>>> "GK" == Georg Koch writes: GK> Hi Barry, hi Developers, when I look into GK> Mailman/Handlers/Decorate.py, it seems to me that it adds a GK> new header part to a multipart/mixed even if the header is GK> empty. Is it so? Best wishes Georg Correct for MM2.0.x. Decorate.py is much smarter (more MIME-friendly) in MM2.1. -Barry From barry@zope.com Wed Aug 1 20:12:11 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 1 Aug 2001 15:12:11 -0400 Subject: [Mailman-Developers] Re: modules relationship References: <15207.42241.672180.698053@anthem.wooz.org> <012e01c11a99$6d3e4340$9baa5882@halls.umist.ac.uk> Message-ID: <15208.21643.751798.828740@anthem.wooz.org> >>>>> "YN" == Yanuar Nugroho writes: YN> If I would like to know how the modules are interrelated each YN> other, along with their functionalities in Mailman, what YN> documentation should I consult? Sorry, there currently aren't any good internals documentation. UTSL! -Barry From barry@zope.com Wed Aug 1 20:19:51 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 1 Aug 2001 15:19:51 -0400 Subject: [Mailman-Developers] MM2.1 DemoList Message-ID: <15208.22103.481301.942379@yyz.digicool.com> I've created a demo list for Mailman 2.1. I'm going to give you the list admin password so you can go in and check out the new admin web pages. See below. A few things to note: - I am not turning on mailmanctl, nor am I installing any of the aliases. This means that the demo list cannot be abused for email, and in fact, no email can reach or leave the list. - If it turns out to be abused anyway, I'll just shut it down. Of course, I trust you guys. :) - At some point, I'll probably decommission this list, and bring up a real demo list, but you'll likely only be able to interact with it from a user point of view. - I really hope you guys will give it a look and send any suggestions or bug reports. I want to very soon start moving toward beta. There are a few more features I want to get in, but I think alpha3 will be the last alpha. I intend to be very strict about feature freeze during the (hopefully short) beta cycle. There's always a cry for more features, from myself included, but at some point you gotta stop or it'll never get released, and I think there are enough good things in the code base now that a new release is warranted. My top priorities during the beta cycle will be 1) fixing bugs; 2) adding a PyUnit test suite; 3) writing documentation; 4) integrating more languages. Enjoy, -Barry http://mail.python.org/mailman-21/admin/demolist password: demolist From ricardo@rixhq.nu Wed Aug 1 20:29:16 2001 From: ricardo@rixhq.nu (Ricardo F. Kustner) Date: Wed, 1 Aug 2001 21:29:16 +0200 Subject: [Mailman-Developers] MM2.1 DemoList In-Reply-To: <15208.22103.481301.942379@yyz.digicool.com> References: <15208.22103.481301.942379@yyz.digicool.com> Message-ID: <20010801212916.77db9dfe.ricardo@rixhq.nu> On Wed, 1 Aug 2001 15:19:51 -0400 barry@zope.com (Barry A. Warsaw) wrote: > I've created a demo list for Mailman 2.1. I'm going to give you the > list admin password so you can go in and check out the new admin web > pages. See below. A few things to note: I'll have a look at it right now... could you put in some test data for pending posts and subscribtions? I'm curious to see what has changed in admindb.py... Thanks... Regards, Ricardo From ricardo@rixhq.nu Wed Aug 1 21:23:15 2001 From: ricardo@rixhq.nu (Ricardo F. Kustner) Date: Wed, 1 Aug 2001 22:23:15 +0200 Subject: [Mailman-Developers] MM2.1 DemoList In-Reply-To: <15208.22103.481301.942379@yyz.digicool.com> References: <15208.22103.481301.942379@yyz.digicool.com> Message-ID: <20010801222315.551bc5f7.ricardo@rixhq.nu> On Wed, 1 Aug 2001 15:19:51 -0400 barry@zope.com (Barry A. Warsaw) wrote: > - I really hope you guys will give it a look and send any suggestions > or bug reports. I want to very soon start moving toward beta. Maybe the web gui design could be improved a bit more... I know this has been discussed in here before, but I don't remember if any conclusions came out of that... I've been configuring quite a few list now, but still I sometimes have to spend some extra time on trying to remember in which section a certain option was and trying to find it on the page... and browsing through the option pages and options means a lot of scrolling up & down of the pages (especially on my 800x600 laptop). I realize it's a bit difficult if you want to stick to standard html with tables (which I completely agree with) but maybe there's some room for improvement...? would it be an idea to put all the section links on the left side of the screen for example? this would save some of the space you loose on the top of the page.... just a thought... -- Regards, Ricardo From barry@zope.com Wed Aug 1 21:38:12 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 1 Aug 2001 16:38:12 -0400 Subject: [Mailman-Developers] Looping digest - mailman bug? References: <15205.38107.541898.68781@daimi.au.dk> Message-ID: <15208.26804.372186.20266@anthem.wooz.org> >>>>> "KPC" == Kaja P Christiansen writes: KPC> Several of our lists suffered from Mailman's mail bombing and KPC> we turned the digest option off in hope it'll help. It did, KPC> for a while, until the same happened with a non-digest KPC> message being send over and over again (once per minute, by KPC> qrunner). KPC> We were able to locate where and how it happens, and to KPC> 'reproduce' the error (in laboratory conditions :-) both KPC> under mailman 2.0.3 and 2.0.6. KPC> The mail looping occurs when there is a MIME message with a KPC> single . (dot) in a line; Mailman sends it to sendmail 'as KPC> is'. But since sendmail/postfix interprets a line with single KPC> dot as the end of the message, it sends everything before the KPC> dot and exits with 'Broken pipe'. Mailman, however, still has KPC> the message in it's queue and sends it all over again... KPC> When I tried sending non-MIME message with single-dot-line in KPC> it to a Mailman list, there was no looping, but the message KPC> body after the single dot was missing. KPC> Until there is something better, I suggest adding to KPC> Sendmail.py a patch which perhaps is not pretty (it adds a KPC> space before the infamous dot), but it works: Okay, several issues going on here. First, let me ask: why are you using Sendmail.py instead of SMTPDirect.py? The former has well known adverse security holes, including being able to trick the shell used during the os.popen() to do evil things. I include your mailbomb example as another security hole in Sendmail.py. I'm strongly considering removing Sendmail.py from MM2.1, but I want to know why some people seem to prefer to use it instead of SMTPDirect.py first. I suspect the reason is because Sendmail tends to want to do recipient domain verification when invoked through smtp, even if the connection is through localhost, while connecting through "sendmail -bs" it does not. If that's the primary reason, then we have two choices: 1) document what Sendmail users should do in order to fix this problem in their MTA, or 2) dig up the patches to enhance smtplib.py to do sendmail -bs connections (I know there have been at least one such contribution, but I'd have to search around for it). I really want everybody to use SMTPDirect.py from now on, so let's fix things so even the Sendmail.py'ers can. >>>>> "TW" == Thomas Wouters writes: TW> Sorry, this is the wrong fix. "\n." isn't the pattern that TW> breaks it; you want "\r?\n.\r?\n". And the proper escape of a TW> single dot on a line is doubling it (see the SMTP standard.) TW> Barry, do you have a clue whether msgtext is guaranteed (not) TW> to have \r's (CR) in them ? If either is guaranteed, we don't TW> even need to use that ugly 're' module :) Now, as to line endings and single-dot termination lines. Python's smtplib does the right thing here, and it fortunately hides everything from the module client. That's a big reason why SMTPDirect.py users never get into trouble; it uses smtplib. smtplib properly line terminates according to RFC 2821 regardless of the line termination of the source text. It also properly implements dot-line transparency according to $4.5.2. On the receiving end, it appears that all the major Unix MTAs properly undo the dot-line escaping, and convert all line endings to Unix line endings (LF-only) before handing the text off to a program or file. I didn't find Postfix documentation on this, but testing and this message http://archives.neohapsis.com/archives/postfix/2000-02/0686.html confirm this to be the case. Exim has a configuration option "use_crlf" which controls this behavior, but since the default value is false, I'm guessing that most Exim installations canonicalize the line endings to Unix-style too. I suspect Sendmail does the same thing, although I haven't found a definitive description yet. So I think it's fair to assume that by the time Mailman's wrapper gets a message, the line endings have all been converted to Unix-style LF termination. So I think Thomas is right that we don't need re and can just check for the first character being a `.' and if so, quote it by adding a leading `.'. But I'm still more inclined to 1) zap Sendmail.py /and/ 2) merge support for sendmail -bs into smtplib.py -Barry From Dale Newfield Wed Aug 1 21:47:57 2001 From: Dale Newfield (Dale Newfield) Date: Wed, 1 Aug 2001 16:47:57 -0400 (EDT) Subject: [Mailman-Developers] MM2.1 DemoList In-Reply-To: <20010801222315.551bc5f7.ricardo@rixhq.nu> Message-ID: On Wed, 1 Aug 2001, Ricardo F. Kustner wrote: > would it be an idea to put all the section links on the left side of > the screen for example? this would save some of the space you loose on > the top of the page.... just a thought... Or just replicate the section links at the bottom of the page, so when you go to a page, scroll through it and not find the item you're looking for, you don't have to scroll all the way back to the top to go to another section? -Dale From ricardo@rixhq.nu Wed Aug 1 21:51:04 2001 From: ricardo@rixhq.nu (Ricardo F. Kustner) Date: Wed, 1 Aug 2001 22:51:04 +0200 Subject: [Mailman-Developers] MM2.1 DemoList In-Reply-To: <20010801222315.551bc5f7.ricardo@rixhq.nu> References: <15208.22103.481301.942379@yyz.digicool.com> <20010801222315.551bc5f7.ricardo@rixhq.nu> Message-ID: <20010801225104.3196c5ec.ricardo@rixhq.nu> On Wed, 1 Aug 2001 22:23:15 +0200 "Ricardo F. Kustner" wrote: > > - I really hope you guys will give it a look and send any suggestions > > or bug reports. I want to very soon start moving toward beta. > would it be an idea to put all the section links on the left side of the > screen for example? this would save some of the space you loose on the > top of the page.... just a thought... here's an illustration of what I mean: http://www.rixhq.nu/mm/demolist.html (it's only 1 html file... nothing is clickable) -- Regards, Ricardo From ricardo@rixhq.nu Wed Aug 1 22:06:12 2001 From: ricardo@rixhq.nu (Ricardo F. Kustner) Date: Wed, 1 Aug 2001 23:06:12 +0200 Subject: [Mailman-Developers] MM2.1 DemoList In-Reply-To: References: <20010801222315.551bc5f7.ricardo@rixhq.nu> Message-ID: <20010801230612.4a9e945e.ricardo@rixhq.nu> On Wed, 1 Aug 2001 16:47:57 -0400 (EDT) Dale Newfield wrote: > On Wed, 1 Aug 2001, Ricardo F. Kustner wrote: > > would it be an idea to put all the section links on the left side of > > the screen for example? this would save some of the space you loose on > > the top of the page.... just a thought... > Or just replicate the section links at the bottom of the page, so when > you > go to a page, scroll through it and not find the item you're looking > for, > you don't have to scroll all the way back to the top to go to another > section? That would be an interesting option as well... but in that case I think the links at the bottom should be abbriviated and put on to 1 or 2 lines: [General Options] * [Membershipmanagement] * [Privacy Options] ... etc [Pending Requests] * [General List Information Page] ... etc hmmm this makes me wonder that maybe one problem with the interface could be that it gives too much information... though this makes it for firsttime users easier to understand the options, it doesn't make it easier to actually find something you're looking for... any GUI experts in here? :) Regards, Ricardo From barry@zope.com Wed Aug 1 22:11:40 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 1 Aug 2001 17:11:40 -0400 Subject: [Mailman-Users] Re: [Mailman-Developers] Looping digest - mailman bug? References: <20010730133518.C61068-100000@phred.org> <20010730233356.D20671@xs4all.nl> Message-ID: <15208.28812.291176.578137@anthem.wooz.org> >>>>> "TW" == Thomas Wouters writes: TW> My question was whether the message text, at that moment, was TW> guaranteed to contain CR's (or guaranteed not to contain TW> them.) I'm not sure what kind of mangling Barry's mimelib does TW> :) I don't think there are any hard guarantees, but certainly current practice seems to be for Unix MTAs to deliver the message locally to file or program with line endings canonicalized to LF only. I actually think this is the right thing to do. Let the protocol specific module deal with massaging the data according to the spec, but let client code deal with it in a natural, albeit platform specific way. mimelib doesn't do any explicit mangling of line endings. Parser uses fp.readline() and Generator uses the print command's implicit line ending behavior which should both adhere to the local line ending conventions. -Barry From claw@2wire.com Wed Aug 1 22:37:47 2001 From: claw@2wire.com (J C Lawrence) Date: Wed, 01 Aug 2001 14:37:47 -0700 Subject: [Mailman-Developers] Re: [Mailman-Users] modules relationship In-Reply-To: Message from "Yanuar Nugroho" of "Wed, 01 Aug 2001 15:51:20 BST." <012e01c11a99$6d3e4340$9baa5882@halls.umist.ac.uk> References: <15207.42241.672180.698053@anthem.wooz.org> <012e01c11a99$6d3e4340$9baa5882@halls.umist.ac.uk> Message-ID: <2333.996701867@2wire.com> On Wed, 1 Aug 2001 15:51:20 +0100 Yanuar Nugroho wrote: > If I would like to know how the modules are interrelated each > other, along with their functionalities in Mailman, what > documentation should I consult? The source? -- J C Lawrence )\._.,--....,'``. ---------(*) /, _.. \ _\ ;`._ ,. claw@kanga.nu `._.-(,_..'--(,_..'`-.;.' http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly From barry@zope.com Wed Aug 1 22:40:03 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 1 Aug 2001 17:40:03 -0400 Subject: [Mailman-Developers] MM2.1 DemoList References: <15208.22103.481301.942379@yyz.digicool.com> <20010801212916.77db9dfe.ricardo@rixhq.nu> Message-ID: <15208.30515.748472.621833@anthem.wooz.org> >>>>> "RFK" == Ricardo F Kustner writes: RFK> could you put in some test data for pending posts and RFK> subscribtions? I'm curious to see what has changed in RFK> admindb.py... I've thought about that, but don't have time for it right now. If I get a chance, I'll seed those databases. -Barry From mentor@alb-net.com Wed Aug 1 22:44:46 2001 From: mentor@alb-net.com (Mentor Cana) Date: Wed, 1 Aug 2001 17:44:46 -0400 (EDT) Subject: [Mailman-Developers] MM2.1 DemoList In-Reply-To: <20010801230612.4a9e945e.ricardo@rixhq.nu> Message-ID: My two cents worth... The usual feedback I get from subscribers is the inability for them to find the way to unsubscribe. Would it be beneficial to emphasize the Unsubscribe process on the listinfo/ page by adding a special heading and button for Unsubscribe similar to "Using " and "Subscribing to " ? Is it doable in 2.1? The "Edit Option" button could be viewed by novice users for changing options, where unsubscribing is not an option since you are just leaving the list. A left menu columns or a top menu on the listinfo/ page would be very beneficial for navigation. -- Mentor Sincerely, Mentor Cana, Coordinator Alb-Net.Com Group http://www.alb-net.com __________________________________________________ Albanians in Macedonia Crisis Center (AMCC) http://www.alb-net.com/amcc On Wed, 1 Aug 2001, at 23:06 +0200, Ricardo F. Kustner wrote: > On Wed, 1 Aug 2001 16:47:57 -0400 (EDT) > Dale Newfield wrote: > > > On Wed, 1 Aug 2001, Ricardo F. Kustner wrote: > > > would it be an idea to put all the section links on the left side of > > > the screen for example? this would save some of the space you loose on > > > the top of the page.... just a thought... > > Or just replicate the section links at the bottom of the page, so when > > you > > go to a page, scroll through it and not find the item you're looking > > for, > > you don't have to scroll all the way back to the top to go to another > > section? > > That would be an interesting option as well... but in that case I think > the links at the bottom should be abbriviated and put on to 1 or 2 lines: > > [General Options] * [Membershipmanagement] * [Privacy Options] ... etc > [Pending Requests] * [General List Information Page] ... etc > > hmmm this makes me wonder that maybe one problem with the interface could > be that it gives too much information... though this makes it for > firsttime users easier to understand the options, it doesn't make it > easier to actually find something you're looking for... > > any GUI experts in here? :) > > Regards, > > Ricardo > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers > From barry@zope.com Thu Aug 2 02:10:53 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 1 Aug 2001 21:10:53 -0400 Subject: [Mailman-Developers] MM2.1 DemoList References: <15208.22103.481301.942379@yyz.digicool.com> <20010801222315.551bc5f7.ricardo@rixhq.nu> Message-ID: <15208.43165.205707.518537@anthem.wooz.org> >>>>> "RFK" == Ricardo F Kustner writes: RFK> Maybe the web gui design could be improved a bit more... No question! :) But at this point, I'm really only interested in small improvements, not wholesale redesigns. One of the things I want to tackle post-2.1 is adoption of a better templating system so that /all/ the web pages can essentially be designed in an HTML gui builder. This will let you completely customize the pages for your site, but still allow Mailman to programmatically fill in various values. (I'm leaning toward ZPT, but that decision is still a long way off). RFK> would it be an idea to put all the section links on the left RFK> side of the screen for example? The easiest thing to do code wise is to duplicate the section links on the bottom of the page. I think I'll do that and leave it at that for now. -Barry From barry@zope.com Thu Aug 2 04:53:26 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 1 Aug 2001 23:53:26 -0400 Subject: [Mailman-Developers] MM2.1 DemoList References: <20010801230612.4a9e945e.ricardo@rixhq.nu> Message-ID: <15208.52918.492123.302372@anthem.wooz.org> >>>>> "MC" == Mentor Cana writes: MC> My two cents worth... MC> The usual feedback I get from subscribers is the inability for MC> them to find the way to unsubscribe. MC> Would it be beneficial to emphasize the Unsubscribe process on MC> the listinfo/ page by adding a special heading and MC> button for Unsubscribe similar to "Using " and MC> "Subscribing to " ? MC> Is it doable in 2.1? MC> The "Edit Option" button could be viewed by novice users for MC> changing options, where unsubscribing is not an option since MC> you are just leaving the list. MC> A left menu columns or a top menu on the listinfo/ MC> page would be very beneficial for navigation. I've reorganized things a bit so that it's clear the "Edit Options" button can be used for unsubscribing as well (the button now reads "Unsubscribe or edit options"). Also, if you leave the field blank, you'll be shown the options login page with an extra field prompting you for your email address. So the "simple unsubscribe directions" can now be explained as: 1. Go to http://www.dom.ain/mailman/options/listname 2. Enter your email address 3. Click on "Unsubscribe" 4. Check your email for confirmation instructions #4 may still be optional if I get to implement open unsubscribes. -Barry From csf@moscow.com Thu Aug 2 07:49:52 2001 From: csf@moscow.com (Michael Yount) Date: Wed, 1 Aug 2001 23:49:52 -0700 Subject: [Mailman-Developers] MM2.1 DemoList In-Reply-To: <15208.22103.481301.942379@yyz.digicool.com>; from barry@zope.com on Wed, Aug 01, 2001 at 03:19:51PM -0400 References: <15208.22103.481301.942379@yyz.digicool.com> Message-ID: <20010801234952.A751@moscow.com> On 01 Aug 15:19, Barry A. Warsaw wrote: > > - I really hope you guys will give it a look and send any suggestions > or bug reports. I want to very soon start moving toward beta. > There are a few more features I want to get in, but I think alpha3 > will be the last alpha. > Three details... In the General Options Section, the admin_immed_notify setting, which says Should administrator get immediate notice of new requests, as well as daily notices about collected ones? doesn't make clear in the brief or detailed description whether or not this applies to the moderators. In the same section, the max_message_size setting says Maximum length in Kb of a message body. Use 0 for no limit. The abbreviation for kilobyte is kB (1000 or 1024) or KB (1024). Perhaps it should be spelled out to avoid confusion. The membership management/membership list section says: Find members by regular expression It would be useful to have a "(Details)" link with an explanation of how to write a regular expression. Michael From kaja@daimi.au.dk Thu Aug 2 14:54:53 2001 From: kaja@daimi.au.dk (Kaja P. Christiansen) Date: Thu, 2 Aug 2001 15:54:53 +0200 Subject: [Mailman-Developers] Looping digest - mailman bug? In-Reply-To: <15208.26804.372186.20266@anthem.wooz.org> References: <15205.38107.541898.68781@daimi.au.dk> <15208.26804.372186.20266@anthem.wooz.org> Message-ID: <15209.23469.63868.630102@daimi.au.dk> Barry A. Warsaw writes: > Okay, several issues going on here. First, let me ask: why are you > using Sendmail.py instead of SMTPDirect.py? I have no weighty reason, I'm afraid. I experimented with both, in early Mailman installations, and recall that there was some problem with getting SMTPDirect to work; setup with Sendmail was fine so I settled for that. > The former has well known > adverse security holes, including being able to trick the shell used > during the os.popen() to do evil things. I include your mailbomb > example as another security hole in Sendmail.py. I'm strongly > considering removing Sendmail.py from MM2.1, but I want to know why > some people seem to prefer to use it instead of SMTPDirect.py first. I no longer have the older versions of Mailman, but current Defaults.py and Sendmail.py do have warning about perils. Maybe one could add it to README.SENDMAIL as well? It would make people stop and reconsider the setup. Thank you for your letter. I made a test configuration of Mailman with SMTPDirect module and there was no trouble at all. Kaja From edlau@ucf.ics.uci.edu Thu Aug 2 20:17:58 2001 From: edlau@ucf.ics.uci.edu (Edmund Lau) Date: Thu, 2 Aug 2001 12:17:58 -0700 (PDT) Subject: [Mailman-Developers] Demolist feedback In-Reply-To: Message-ID: Under Digest Options for the demolist, how about changing "Should Mailman start a new digest volume?" to "Should Mailman start a new digest volume right now?" I'm assuming that's what it means. -Ed From Dan Mick Thu Aug 2 20:22:24 2001 From: Dan Mick (Dan Mick) Date: Thu, 2 Aug 2001 12:22:24 -0700 (PDT) Subject: [Mailman-Developers] Clean output with bin/withlist?? Message-ID: <200108021922.MAA20889@utopia.West.Sun.COM> > def hostname(m): > print m.host_name > > % bin/withlist -q -r hostname mylist > wooz.org Who needs -q? Everything but the output comes to stderr; the desired output comes to stdout. This has been true for some time now, no? From Dan Mick Fri Aug 3 03:43:12 2001 From: Dan Mick (Dan Mick) Date: Thu, 2 Aug 2001 19:43:12 -0700 (PDT) Subject: [Mailman-Developers] MM2.1 DemoList Message-ID: <200108030242.TAA16203@utopia.West.Sun.COM> > MC> The usual feedback I get from subscribers is the inability for > MC> them to find the way to unsubscribe. > I've reorganized things a bit so that it's clear the "Edit Options" > button can be used for unsubscribing as well (the button now reads > "Unsubscribe or edit options"). Also, if you leave the field blank, > you'll be shown the options login page with an extra field prompting > you for your email address. So the "simple unsubscribe directions" > can now be explained as: > > 1. Go to http://www.dom.ain/mailman/options/listname > 2. Enter your email address > 3. Click on "Unsubscribe" > 4. Check your email for confirmation instructions > > #4 may still be optional if I get to implement open unsubscribes. Strong vote here for moving the "options" further up the page. Those who are just looking can scroll past the "if you're a current member" stuff or not, I don't care, but I want my subscribers to see the " Subscribers" section immediately without scrolling. Also, yes, I think the title should be clear. In fact, I think the "Visit Subscriber List" should not be in this section. In fact, I'd go as far as, up near the top, adding a new major section (perhaps right after About ): --- Unsubscribing To unsubscribe from , enter your subscription email address: ---- and then I'd probably move " Subscribers" up there too. Service your current customers higher on the page; let people who want to subscribe be the ones who scroll... From ariashheart@mail.com Fri Aug 3 05:04:53 2001 From: ariashheart@mail.com (Discount Web Shopping) Date: Fri, 3 Aug 2001 00:04:53 -0400 Subject: [Mailman-Developers] Relax, NEW! Electronic Pulse Massager Message-ID:

Hello,

You are receiving this Email as an "OPT-IN" mailer. This means that you have requested this type of TREMENDOUS OFFER to be directly Emailed to you. This is a ONE TIME Email. You will NOT be receiving this offer again. Do not miss out on this GREAT DEAL!!!!

If you are not interested in this item, please excuse the intrusion into your Email Inbox (this will not be Emailed to you again). Please click on the link below if you would like to take advantage of this ONE TIME DEAL:

HTTP://DISCOUNTWEBSHOPPING.COM

 

We offer HIGH QUALITY products at BELOW WHOLESALE prices!!!

The product below is our SPECIAL OF THE DAY!!!

How can we offer such products at these ridiculous prices? The answer is quite simple, VOLUME! We at DISCOUNT WEB SHOPPING purchase hundreds and even thousands of items direct from the manufacturers in Asia, Europe and the USA. By purchasing directly from the source, there is no "middle man" which allows us to buy at "way below wholesale" prices. We then pass the savings on to you!

All orders placed by credit card are processed through Authorize.net and are totally SECURE!

 

Thank you for taking advantage of the BEST DEALS on the internet!!!

CHECK BACK EVERYDAY TO VIEW OUR "SPECIAL OF THE DAY"!!!

 

ELECTRONIC PULSE MASSAGER!!!

THE HOTTEST NEW TECHNOLOGY IN
MASSAGE THERAPY!!!

YOU WILL NOT BELIEVE THE POWER!!!

COMES WITH ACU-PEN WHICH STIMULATES AREAS OF THE BODY FOR ACUPUNCTURE TYPE RELIEF AND COMFORT!!!

MSRP $429.99!!!

YOUR PRICE: $64.88!!!

We are so confident that you will not find a lower price on this item, we ask you now to please go search for this item on the internet and see if someone can even come close to this price. We have already searched ourselves and the lowest price we could find is $199.95.

NOTE: Please remember to save this page in your favorites before your search begins because you will definitely want to come back!

The use of Facial Pad

What is Electronic Pulse Massager?
This high quality electronic pulse massager has been designed in Japan and manufactured in Korea to stimulate muscles to help massage,relax, and relieve pain quickly by generating safe low
frequency pulse stimulation electronically.

Specification
Model : Two-Way Electronic Pulse Massager Size(Main Body): 15mmx60mmx100mm
Mode : Tap, Vibrating, Massage, Auto.
Voltage : DC3V(AAAx2), Battery included.
Content : Main body, facial pad, acu-pen, acu-pad
lead wire, holder, user manual, battery, electrodes.

The use of Acu-Pen

NEW TECHNOLOGY IN MASSAGE THERAPY!!!

SOLD ELSEWHERE AT DISCOUNT FOR $299.95!!!

1 YEAR WARRANTY!!!


**** DON"T MISS THIS GREAT DEAL!!!!!!

 

Please add $9 shipping and handling to each order within the Continental US. No additional charge for more than one item up to 10 units.

Alaska, Hawaii, Canada and the Carribean, please add $15.

All other Worldwide International shipments please add $25.

Please click on the link below if you would like to take advantage of the ONE TIME DEAL:

http://discountwebshopping.com

Thank you for your time. This is a ONE TIME Email. You will not be receiving this offer again. From barry@zope.com Fri Aug 3 05:50:41 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 3 Aug 2001 00:50:41 -0400 Subject: [Mailman-Developers] MM2.1 DemoList References: <15208.22103.481301.942379@yyz.digicool.com> <20010801234952.A751@moscow.com> Message-ID: <15210.11681.333407.144344@anthem.wooz.org> >>>>> "MY" == Michael Yount writes: MY> Three details... Cool, thanks! MY> In the General Options Section, the admin_immed_notify MY> setting, which says >> Should administrator get immediate notice of new requests, as well >> as daily notices about collected ones? MY> doesn't make clear in the brief or detailed description MY> whether or not this applies to the moderators. Good point. I've clarified this (it does send to the moderators too). MY> In the same section, the max_message_size setting says MY> Maximum length in Kb of a message body. Use 0 for no limit. MY> The abbreviation for kilobyte is kB (1000 or 1024) or KB MY> (1024). Perhaps it should be spelled out to avoid confusion. Done. MY> The membership management/membership list section says: MY> Find members by regular expression MY> It would be useful to have a "(Details)" link with an MY> explanation of how to write a regular expression. A (Details) link is a bit inconvenient there. I've changed it to read "Find members by Python regular expression" where the last three words are hyperlinked to the section of the Python library reference defining regular expression syntax. -Barry From barry@zope.com Fri Aug 3 06:06:17 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 3 Aug 2001 01:06:17 -0400 Subject: [Mailman-Developers] Demolist feedback References: Message-ID: <15210.12617.742279.437690@anthem.wooz.org> >>>>> "EL" == Edmund Lau writes: EL> Under Digest Options for the demolist, how about changing EL> "Should Mailman start a new digest volume?" EL> to EL> "Should Mailman start a new digest volume right now?" I'm EL> assuming that's what it means. Actually, it means that the next digest sent out will have a new volume number. The details of that variable explain it -- is that good enough? -Barry From balzer@bbcomp.de Fri Aug 3 09:20:05 2001 From: balzer@bbcomp.de (Michael Balzer) Date: Fri, 3 Aug 2001 10:20:05 +0200 Subject: [Mailman-Developers] cron/mailpasswds Message-ID: <013e01c11bf6$e256ab00$fe78a8c0@bbcomp.de> dear mm developers, may i suggest a change to cron/mailpasswds? instead of using the same from address for all passwd notifications, use a from address that reflects the domain (virtual host). reason: all replies to passwd reminders now go to the main mailman-owner. it should be possible to direct them to the mailman-owner of the domain instead. diff: 61d60 < mailman_owner = mm_cfg.MAILMAN_OWNER 62a62 > mailman_owner = 'mailman-owner@' + host with a bit more context: ... for host, users in hosts.items(): mailman_owner = 'mailman-owner@' + host subj = host + ' mailing list memberships reminder' ... this change should be accompanied by a config var for the 'mailman-owner' part + a documentation change, so users know they can add some mailman-owner@domain.com address for each virtual list domain. mfg, michael balzer ps: please reply to me directly, i'm not subscribed. -- 2BCom IT Solutions / Hasslinghauser Str. 156 / D-58285 Gevelsberg Fon +49 2332 7588-0 / Fax -11 / http://www.bbcomp.de From barry@zope.com Fri Aug 3 17:33:50 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 3 Aug 2001 12:33:50 -0400 Subject: [Mailman-Developers] MM2.1 DemoList References: <200108030242.TAA16203@utopia.West.Sun.COM> Message-ID: <15210.53870.256491.57805@anthem.wooz.org> >>>>> "DM" == Dan Mick writes: DM> Strong vote here for moving the "options" further up the page. DM> Those who are just looking can scroll past the "if you're a DM> current member" stuff or not, I don't care, but I want my DM> subscribers to see the " Subscribers" section DM> immediately without scrolling. Also, yes, I think the title DM> should be clear. In fact, I think the "Visit Subscriber List" DM> should not be in this section. DM> In fact, I'd go as far as, up near the top, adding a new major DM> section (perhaps right after About ): | --- | Unsubscribing DM> To unsubscribe from , enter your subscription email DM> address: ---- DM> and then I'd probably move " Subscribers" up there DM> too. Service your current customers higher on the page; let DM> people who want to subscribe be the ones who scroll... There's some good ideas here, but I'm going to put them off for now so I can get the last couple of features in. I think we can tweak the UI during the beta cycle. -Barry From jarrell@vt.edu Fri Aug 3 22:42:05 2001 From: jarrell@vt.edu (Ron Jarrell) Date: Fri, 03 Aug 2001 17:42:05 -0400 Subject: [Mailman-Developers] MM2.1 DemoList In-Reply-To: <15210.11681.333407.144344@anthem.wooz.org> References: <15208.22103.481301.942379@yyz.digicool.com> <20010801234952.A751@moscow.com> Message-ID: <5.1.0.14.2.20010803173928.0264e290@lennier.cc.vt.edu> At 12:50 AM 8/3/01 -0400, Barry A. Warsaw wrote: > MY> The abbreviation for kilobyte is kB (1000 or 1024) or KB > MY> (1024). Perhaps it should be spelled out to avoid confusion. Actually KB isn't an official standard for multiples of 1024. Computer people are just supposed to know when a K means 1000, and when it means 1024. That's why Nist invented Kebi. A Kebibyte, or KeB is based on 1024 (As are Mebibytes, and Gebibytes.) Not, mind you, that you'll ever catch me pronouncing them outloud. Yours in extreme nitpickiness, -Ron From Dan Mick Fri Aug 3 23:25:18 2001 From: Dan Mick (Dan Mick) Date: Fri, 3 Aug 2001 15:25:18 -0700 (PDT) Subject: [Mailman-Developers] MM2.1 DemoList Message-ID: <200108032225.PAA15887@utopia.West.Sun.COM> > At 12:50 AM 8/3/01 -0400, Barry A. Warsaw wrote: > > MY> The abbreviation for kilobyte is kB (1000 or 1024) or KB > > MY> (1024). Perhaps it should be spelled out to avoid confusion. > > Actually KB isn't an official standard for multiples of 1024. Computer > people are just supposed to know when a K means 1000, and when > it means 1024. That's why Nist invented Kebi. You mean "NIST". ;) > A Kebibyte, or KeB is > based on 1024 (As are Mebibytes, and Gebibytes.) Not, mind you, that > you'll ever catch me pronouncing them outloud. Not that you'll ever catch me using them, either. The only people who care are disk drive manufacturers, who lie like rugs on a continuing basis. Everyone else knows what a kilobyte or a megabyte really is, despite the otherwise-annoying imprecision, and has been using it for more than 30 years, so NIST can go pound sand, IMO. From barry@zope.com Fri Aug 3 23:59:20 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 3 Aug 2001 18:59:20 -0400 Subject: [Mailman-Developers] MM2.1 DemoList References: <15208.22103.481301.942379@yyz.digicool.com> <20010801234952.A751@moscow.com> <5.1.0.14.2.20010803173928.0264e290@lennier.cc.vt.edu> Message-ID: <15211.11464.626951.486784@anthem.wooz.org> I thought a mebibyte was what my evil cat did when I pet her. -Barry From jarrell@vt.edu Sat Aug 4 01:34:32 2001 From: jarrell@vt.edu (Ron Jarrell) Date: Fri, 03 Aug 2001 20:34:32 -0400 Subject: [Mailman-Developers] sendmail Message-ID: <5.1.0.14.2.20010803203144.03f44840@lennier.cc.vt.edu> Ok, so the main problem people have with sendmail and mailman is that using the smtpdirect approach with a busy machine costs too much hang time at both the MAIL FROM and the RCPT TO anti-relay/spam testing points, right? And what we want is a way to configure it to continue to validate against J. Random connection coming in to port 25 from whereever in the world, but if the connection comes from 127.0.0.1, we want it to just basically shut up and take the message. Does that about sum it up? From barry@zope.com Sat Aug 4 01:49:01 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 3 Aug 2001 20:49:01 -0400 Subject: [Mailman-Developers] sendmail References: <5.1.0.14.2.20010803203144.03f44840@lennier.cc.vt.edu> Message-ID: <15211.18045.192807.371887@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> Ok, so the main problem people have with sendmail and mailman RJ> is that using the smtpdirect approach with a busy machine RJ> costs too much hang time at both the MAIL FROM and the RCPT TO RJ> anti-relay/spam testing points, right? And what we want is a RJ> way to configure it to continue to validate against J. Random RJ> connection coming in to port 25 from whereever in the world, RJ> but if the connection comes from 127.0.0.1, we want it to just RJ> basically shut up and take the message. RJ> Does that about sum it up? Yes, I think so. It would be great if you could communicate with the Sendmail folks to make sure that it can be configured this way for Mailman sites. I'll offer to help in any way I can, so feel free to forward my email to them if necessary. It would be great if Mailman and Sendmail could play better together. Thanks, -Barry From mentor@alb-net.com Sat Aug 4 02:13:05 2001 From: mentor@alb-net.com (Mentor Cana) Date: Fri, 3 Aug 2001 21:13:05 -0400 (EDT) Subject: [Mailman-Developers] sendmail In-Reply-To: <15211.18045.192807.371887@anthem.wooz.org> Message-ID: Is it possible to configure Postfix this way? That is: "to validate against J. Random connection coming in to port 25 from whereever in the world, but if the connection comes from 127.0.0.1, we want it to just basically shut up and take the message." thanks, Mentor On Fri, 3 Aug 2001, at 20:49 -0400, Barry A. Warsaw wrote: > > >>>>> "RJ" == Ron Jarrell writes: > > RJ> Ok, so the main problem people have with sendmail and mailman > RJ> is that using the smtpdirect approach with a busy machine > RJ> costs too much hang time at both the MAIL FROM and the RCPT TO > RJ> anti-relay/spam testing points, right? And what we want is a > RJ> way to configure it to continue to validate against J. Random > RJ> connection coming in to port 25 from whereever in the world, > RJ> but if the connection comes from 127.0.0.1, we want it to just > RJ> basically shut up and take the message. > > RJ> Does that about sum it up? > > Yes, I think so. It would be great if you could communicate with the > Sendmail folks to make sure that it can be configured this way for > Mailman sites. I'll offer to help in any way I can, so feel free to > forward my email to them if necessary. > > It would be great if Mailman and Sendmail could play better together. > > Thanks, > -Barry > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers > From barry@zope.com Sat Aug 4 02:34:07 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 3 Aug 2001 21:34:07 -0400 Subject: [Mailman-Developers] Two new features, partially cooked Message-ID: <15211.20751.414844.876484@anthem.wooz.org> I wanted to get this in now so that people can play with them. I will likely be unresponsive to email over the next week to 10 days, so apologies in advance. First, I had a brainstorm about how to do personalized email, at least for regular deliveries. I think this is essentially what people who do announce-only lists feel is missing. It's not really VERP, it's not tied into the bounce detector, and it doesn't (currently) work for digest deliveries, but it does allow you to add headers and footers which have %()s expansions personalized for each recipient. As guessed, personalized lists mean that Mailman makes a copy of the message for each recipient, so it explodes the work being done by #msgs x #recips. The details for the option (look under "Non-digest deliveries") try to explain the implications of turning this on. Note that the site administrator must explicitly enable personalized lists by setting OWNERS_CAN_ENABLE_PERSONALIZATION. Second, I've wormed around the bogus problem with password reminders coming from a random public list. Here's how it currently works: - you must create a "site list" which by default is "mailman", but which you can really give any name as long as you change MAILMAN_SITE_LIST. - For each virtual host, the password reminders look like they're coming from mailman-request@vhost, where "mailman-request" is really MAILMAN_SITE_LIST-request. - MAILMAN_OWNER is gone as a configuration variable. Wherever it was referenced before, Mailman now uses MAILMAN_SITE_LIST, with the host_name coerced to whatever vhost is appropriate (either based on the mailing list the action is being taken on, or the host name as calculated from the web request). This seems to work, and I think is better than the old approach, but it's not perfect. For one thing, MAILMAN_SITE_LIST is just a normal old list; there's nothing special about it except that it's named in MAILMAN_SITE_LIST. Second, we're relying on the, er, feature that listnames share a namespace across vhosts, so MAILMAN_SITE_LIST@vhost1 == MAILMAN_SITE_LIST@vhost2. Post MM2.1, when we have true virtual hosting, this will have to be fixed, and MAILMAN_SITE_LIST will likely be made special. Also, nothing checks to make sure this site list exists, so at the very least the installation docs will have to make it clear you need to create this list (possibly as a way to test your Mailman installation, so that could work fairly well). Anyway, neither feature is ideally implemented, but I think it's the best I can do for now. I know there'll be lots of room for improvement, but I'd like to know if you think these will work for MM2.1 as they are, or if something's fundamentally bolluxed about them. Check-ins coming soon -- I need to eat first! :) Thanks, -Barry From jarrell@vt.edu Sat Aug 4 02:46:38 2001 From: jarrell@vt.edu (Ron Jarrell) Date: Fri, 03 Aug 2001 21:46:38 -0400 Subject: [Mailman-Developers] sendmail In-Reply-To: <15211.18045.192807.371887@anthem.wooz.org> References: <5.1.0.14.2.20010803203144.03f44840@lennier.cc.vt.edu> Message-ID: <5.1.0.14.2.20010803211659.04297e20@lennier.cc.vt.edu> Ok, if anyone else running sendmail would like to test this a bit, I'd appreciate it. You need to be running at least 8.11 I believe. (And if you're running 8.11, you ought to be at 8.11.4) Take your whatever.mc file and add this: To your features: FEATURE(no_default_msa)dnl Down further: DAEMON_OPTIONS(`Name=MTA')dnl DAEMON_OPTIONS(`Port=587,Name=MSA,M=E,Addr=127.0.0.1')dnl (Note, if you've already customized your MTA with DAEMON_OPTIONS, that's fine, you just *have* to specify at least that much if you're going to configure the MSA to do something non default. Personally, I add a "Listen=32" to my MTA to expand my tcp listen queue.) Then down at the bottom: LOCAL_RULESETS SLocal_check_rcpt # If it's coming from port 587, let it through R$* $: $&{daemon_port} R587 $#OK SLocal_check_mail # If it's coming from port 587, let it through R$* $: $&{daemon_port} R587 $#OK Note that the whitespace in those rules is tabs. Now tell mailman to use the MSA port, which is 587, and see if your throughput jumps up. This will let you put, basically, any old crap into the MAIL FROM or the RCPT TO, if it's coming from the MSA port on the localhost, but continue to validate normal mail traffic. Of course, bogus addresses will bounce later anyway. By not checking the mail from we avoid the "unresolvable sender address" checks, which is ok, because we're assuming the inbound mail was tested anyway. Seems to work ok in my testing. I've also re-written dgc's mc hacks that support the mm-handler he wrote into a mailer directive, so you can include them into your MC file as a "MAILER(mailman)", but that's a whole separate topic. Note, this isn't the prettiest method, but it seems to work, and we're looking at alternatives for 8.12. I've also bundled up an incomplete sample mc file for a mail man machine that includes the mailman mailer to handle the aliases that dgc wrote, as well as the proposed changes. It's not intended to be used as is, it's a guide for merging it with your own installation. It, my mailman.m4 configuration file, and the current copy I have from dgc of mm-handler (which I haven't touched, and I only provide here because he's on vacation and hasn't had a chance to release a new version of it) can be found at: http://babylon5.cc.vt.edu/~jarrell/mailman Let me know if we're on the right track here. From Dan Mick Sat Aug 4 02:49:52 2001 From: Dan Mick (Dan Mick) Date: Fri, 3 Aug 2001 18:49:52 -0700 (PDT) Subject: [Mailman-Developers] sendmail Message-ID: <200108040149.SAA22723@utopia.West.Sun.COM> I've come to the conclusion that 1) postfix takes the message no matter what synchronously and queues it, which eliminates a lot of the wait problems, and 2) yes, the validation step can be short-circuited with things like "mynetworks" and "relaydomains" and that set of stuff, and I think the "default" is to allow locally-originated mail to go out without sender-DNS lookups. > Is it possible to configure Postfix this way? That is: "to validate against > J. Random connection coming in to port 25 from whereever in the world, > but if the connection comes from 127.0.0.1, we want it to just basically > shut up and take the message." > > thanks, > Mentor > > On Fri, 3 Aug 2001, at 20:49 -0400, Barry A. Warsaw wrote: > > > > > >>>>> "RJ" == Ron Jarrell writes: > > > > RJ> Ok, so the main problem people have with sendmail and mailman > > RJ> is that using the smtpdirect approach with a busy machine > > RJ> costs too much hang time at both the MAIL FROM and the RCPT TO > > RJ> anti-relay/spam testing points, right? And what we want is a > > RJ> way to configure it to continue to validate against J. Random > > RJ> connection coming in to port 25 from whereever in the world, > > RJ> but if the connection comes from 127.0.0.1, we want it to just > > RJ> basically shut up and take the message. > > > > RJ> Does that about sum it up? > > > > Yes, I think so. It would be great if you could communicate with the > > Sendmail folks to make sure that it can be configured this way for > > Mailman sites. I'll offer to help in any way I can, so feel free to > > forward my email to them if necessary. > > > > It would be great if Mailman and Sendmail could play better together. > > > > Thanks, > > -Barry > > > > _______________________________________________ > > Mailman-Developers mailing list > > Mailman-Developers@python.org > > http://mail.python.org/mailman/listinfo/mailman-developers > > > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers From darrell@grumblesmurf.net Sat Aug 4 22:14:06 2001 From: darrell@grumblesmurf.net (Darrell Fuhriman) Date: 04 Aug 2001 14:14:06 -0700 Subject: [Mailman-Developers] sendmail In-Reply-To: barry@zope.com's message of "Fri, 3 Aug 2001 20:49:01 -0400" References: <5.1.0.14.2.20010803203144.03f44840@lennier.cc.vt.edu> <15211.18045.192807.371887@anthem.wooz.org> Message-ID: barry@zope.com (Barry A. Warsaw) writes: > It would be great if Mailman and Sendmail could play better together. Well, you could include my address sorting patch -- it does help sendmail's performance quite a lot. :-| The onus can't be put solely on sendmail, especially since Mailman could do something of little of little cost but great benefit. That being said, for Mailman, I run sendmail on a second port with only Mailman uses. /usr/lib/sendmail -bd -ODeliveryMode=defer \ -ODaemonPortOptions=Name=Mailman,Port=26 You could also use that to bind only to localhost. The only downside to this method is that messages won't be sent until the queue is run on the normal interval. I run only a couple of relatively low traffic lists, and like the quick turnaround, I myself got around that problem by writing a wrapper around qrunner that runs the queue when qrunner finishes, but only processes things that were put in the queue within the last N minutes (currently fifteen). -- /usr/local/bin/python -S /usr/local/mailman/cron/qrunner exec /usr/lib/sendmail `/usr/local/mailman/bin/qid` > /dev/null -- The qid program is below. The whole thing is a bit kludgey, but it does the right thing. Darrell #!/usr/local/bin/perl # in which we generate a partial sendmail queue identifier for the # current minute. We have just translated this from sendmail's # code. use Time::gmtime; @Base60Code=split('', "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwx"); foreach $i (0 .. 15) { undef $idbuf; $gm = gmtime(time - ($i*60)); $idbuf .= $Base60Code[$gm->year() % 60]; $idbuf .= $Base60Code[$gm->mon()]; $idbuf .= $Base60Code[$gm->mday()]; $idbuf .= $Base60Code[$gm->hour()]; $idbuf .= $Base60Code[$gm->min()]; print "-qI${idbuf} "; } From marc_news@valinux.com Tue Aug 7 01:08:10 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Mon, 6 Aug 2001 17:08:10 -0700 Subject: [Mailman-Developers] suggestion for sending monthly reminders Message-ID: <20010806170810.S13561@magic.merlins.org> So, I have the problem that I obviously get a bunch of bounces every month when the mailing list membership Emails leave. The envelope sender is test-admin@lists.sf.net while the header sender is mailman-owner@lists.sf.net. Of course, we get a bunch of bounces at the header sender address from MTAs and stupid autoresponders that don't respect basic mail protocols (i.e. automated bounces always go to the envelope sender) Some people have however written back saying that their autoresponder is safe, and that it's ok to bounce back to the header sender as long as the original receipient was listed in To: or Cc: I happen to disagree with that, but unfortunately I've never found an RFC to support my side of the argument. In the meantime, I've written this: http://marc.merlins.org/netrants/autoresponders.txt I am currently unsubscribing on sight any person who bounces back to the header sender because I do not want to see loops on my lists, but I thought that it might be a bit more civil if I sent the membership reminder with a To: field of so that if anyone still bounces a mail like this, they can really be removed, and even in some automated way. I had a quick look at the mailman code, and apparently mailpasswd calls other functions so I didn't find a quick way to hack that. 1) Do people agree that optionally not listing the receipient of the reminder in monthly password reminders could be a good thing? 2) I'd also add the receipient in the subject line (i.e. "Password reminder for foobar@provider.tld" as many broken autoresponders don't bounce the body and bounce from another address so you have no clue where the bounce came from (they usually are nice enough to leave the subject line mostly intact, so that's sometimes the only way to see who is bouncing) 3) Is there a quick way to hack that in the mm source? Thanks, Marc -- 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 Nigel.Metheringham@Intechnology.co.uk Tue Aug 7 10:10:51 2001 From: Nigel.Metheringham@Intechnology.co.uk (Nigel Metheringham) Date: 07 Aug 2001 10:10:51 +0100 Subject: [Mailman-Developers] suggestion for sending monthly reminders In-Reply-To: <20010806170810.S13561@magic.merlins.org> References: <20010806170810.S13561@magic.merlins.org> Message-ID: <997175456.3767.14.camel@gaspode.localnet> On 06 Aug 2001 17:08:10 -0700, Marc MERLIN wrote: > 1) Do people agree that optionally not listing the receipient of the > reminder in monthly password reminders could be a good thing? With the provisio that the message should include the actual subscribed address of the subscriber... since some people can never tell what address they subscribed :-) Nigel. From Kevinmk@usa.com Tue Aug 7 11:06:09 2001 From: Kevinmk@usa.com (Kevinmk@usa.com) Date: Tue, 07 Aug 01 05:06:09 EST Subject: [Mailman-Developers] First? or Last? Message-ID: Hello, Are you looking for your first Internet business...or your last? If it's your first, wouldn't you like it to be your last? Your last should be like going home....it should be the one that allows you to double your full time income on a part time basis, is stable, will be there for your heirs, and give you the lifestyle you dream of. May I have your permission to send you a URL link to show you an internet run, rapidly expanding leg in a company that has a 16 year track record, 15 years of double digit growth, no inventory to buy or sell, and whose successful representative have nearly all found this to be the "last" business they needed? Just reply to this letter with "show me" in the subject line and I'll send the link along. (If you'd like to receive additional info by snail mail, please include your full name, address, and phone in the body.) Best Regards, Kevin *To be removed from this list please reply with REMOVE as the Subject* From marc_news@valinux.com Tue Aug 7 16:25:58 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Tue, 7 Aug 2001 08:25:58 -0700 Subject: [Mailman-Developers] suggestion for sending monthly reminders In-Reply-To: <997175456.3767.14.camel@gaspode.localnet>; from Nigel.Metheringham@Intechnology.co.uk on Tue, Aug 07, 2001 at 10:10:51AM +0100 References: <20010806170810.S13561@magic.merlins.org> <997175456.3767.14.camel@gaspode.localnet> Message-ID: <20010807082558.B29552@magic.merlins.org> On Tue, Aug 07, 2001 at 10:10:51AM +0100, Nigel Metheringham wrote: > On 06 Aug 2001 17:08:10 -0700, Marc MERLIN wrote: > > 1) Do people agree that optionally not listing the receipient of the > > reminder in monthly password reminders could be a good thing? > > With the provisio that the message should include the actual subscribed > address of the subscriber... since some people can never tell what > address they subscribed :-) Yes, that was #2 (adding the subscriber in the subject line) It's also mentionned inside the body: ---------------------------------------------------------------------------- Passwords for user@domain: List Password // URL ---- -------- ia-64-userspace@lists.sourceforge.net foo http://lists.sourceforge.net/mailman/options/ia-64-userspace/user@domain ---------------------------------------------------------------------------- Marc -- 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 Dan Mick Tue Aug 7 22:25:55 2001 From: Dan Mick (Dan Mick) Date: Tue, 7 Aug 2001 14:25:55 -0700 (PDT) Subject: [Mailman-Developers] current cvs: no mailman.mo for big5? Message-ID: <200108072125.OAA14504@utopia.West.Sun.COM> The build of the current CVS fails because there's no .mo file corresponding to messages/big5/LC_MESSAGES/mailman.po. The rest of the .mo files are in CVS. Is this something that I can create, somehow, or does Barry have to? Totally-new-to-Python-and-Mailman-I18N'ly yours, Dan From benwa@ocentrix.com Wed Aug 8 00:26:11 2001 From: benwa@ocentrix.com (Ben Burnett) Date: Tue, 7 Aug 2001 16:26:11 -0700 Subject: [Mailman-Developers] 2.0.3 email interface custom who command on closed list Message-ID: <200108072326.f77NQBC20687@mail.ocentrix.net> Has anyone hacked the who command for the email interface to work with a closed list? I'm looking for something like: who where password is the list admin password and will also allow the site admin password. If not, maybe I'll give it a go. I'd rather not reinvent the wheel though. Thanks, Ben PS I searched the archives and didn't see anything relevant using the terms: who command closed list. If anyone has ideas for other terms I'm all ears. From ddusa@ziplip.com Tue Aug 7 18:39:25 2001 From: ddusa@ziplip.com (ddusa) Date: Tue, 7 Aug 2001 17:39:25 Subject: [Mailman-Developers] $12 Investment...$10,000 Return!!! Message-ID: THIS IS THE SUPER FAST ONE!!!!! While you're waiting for the others to work, this little gem will put $10,00 in your pockett in as little as two weeks!!..I guarantee it!! Your only cost is a couple hours of your time and $10 or $20. That's it. THE GIFTING CLUB (please take two min. to read this) If you want to make several thousand dollars really quick, then please take two minutes to read and understand the program I am sharing with you. No this is not what you think. You do not have to send $5 to five people to buy a report, receipt, or get their mailing list. Nor will you need to invest more money later to get things going. THIS IS THE FASTEST EASIEST PROGRAM YOU"VE EVER SEEN Complete this in a couple hours and you'll never forget the day you received it. If you are doing other programs, by all means stay with them. The more the merrier...please read on. First, there are only three levels, not four, five or even nine like some other programs. This three level program is much more realistic and much, much faster because it is so easy. The response to this program is VERY HIGH and VERY FAST!! You receive your money in a couple weeks, not a couple months. TRUE STORY: Cindy Allen ran this summation four times last year. The first time she received $3,000 in two weeks and $7,000 the next three weeks. When this program is continued, as it should be, EVERYONE PROFITS!! Don't be afraid to gift a stranger. There's an old saying that gifts will come back to you ten fold. THE DETAILS: You only need to mail out 20 copies, not 200 or more like other programs. Mail them to friends, relatives, poeple who send you their programs, people who you know will continue the process. Even if you're now in another program, stay with it by all means, but do yourself a favor, do this one as well!! It is very simple and takes a very small ( $10 to $20 ) investment. This will be big before the others even trickle in. Just give ONE person $5. That's it!! Follow the simple instructions and in a couple weeks you'll have $10,000 because most people will respond to the low investment high speed and huge profit potential. So lets's help each other by keeping it going!! 1. On a blank piece of paper write your name, address, and email address LEGIBLY and wrap it around a FIVE dollar bill. Send it to the FIRST person on the list below ( #1 ). ONLY THAT PERSON ON THE LIST GETS YOUR NAME AND A $5 BILL!! 2. Retype the list, REMOVE the FIRST NAME ( #1 ) from the list. Move the other two names up and add your name in the ( #3 ) position. 3. If you're using snail mail, make however many copies you're sending out, ( at least 20 ) and send them out today!!! If you're using email, make your initial mailing now and save it. Every time you recieve an opportunity letter, mail them this. There is no more to do. When your name reaches the first position, it will be your turn to collect all your gifts. Can you do it?? Of course you can. Get creative. Each time you recieve a "Get Rich Quick" or "MLM" offer in the mail or your email, respond with THIS LETTER. Your name will climb to the #1 position at dizzying rates. Some of you may want to purchase mailing lists or send out hundreds or even thousands of letters. That's great. The sky really is the limit with this unique GIFTING CLUB. ACT FAST AND GET PAID FAST! Honesty and Integrity make this plan work. Send $5 to the first name only. Remove that name and move the other two up one position. Add your name to position ( #3 ). Copy names and addresses EXACTLY. #1. Daniel Weaver, P.O. Box 7, Clarksburg, MO 65025 #2. S. Denyer, P.O. Box 406, Triangle, VA 22172 #3. Bayberry Store, 114 S. Main #305, Fond du Lac, WI 54935 This is a one time mailing so no need to remove. If you wish we will remove your name from our data base. Type remove in the subject line and email ddusa@ziplip.com . From do-risika@simicro-internet.mg Wed Aug 8 12:09:43 2001 From: do-risika@simicro-internet.mg (Do-Risika RAFIEFERANTSIARONJY) Date: Wed, 08 Aug 2001 14:09:43 +0300 Subject: [Mailman-Developers] change PREFIX and VAR-PREFIX directory ... Message-ID: <3B711DF7.D12BA46B@simicro-internet.mg> Hello, Is it possible to change the PREFIX directory after an installation ? In fact, I installed mailman through apt-get/debian and want now to change the --prefix and the --var-prefix directory into /var/mailman. Can I add this line below in mm_cfg.py to do that ? or is there another way ? PREFIX = '/var/mailman' Thanx. -- Do-Risika RAFIEFERANTSIARONJY mailto:do-risika@simicro-internet.mg ~~~~~~~~~~~~~~~~ Simicro Internet Email : simicro@simicro.mg Web : http://www.simicro.mg Tel : 261 20 22 648 83 (GMT +3) Fax : 261 20 22 661 83 From dan.mick@west.sun.com Wed Aug 8 20:13:58 2001 From: dan.mick@west.sun.com (Dan Mick) Date: Wed, 08 Aug 2001 12:13:58 -0700 Subject: [Mailman-Developers] Language selection in 2.1 Message-ID: <3B718F76.17EA1E55@west.sun.com> Just CVSed to latest and installed a test machine. I only seem to get 'en' showing up in the various web-interface dropdown boxes for available languages or GUI-page translations. Is there some manual step to enable other languages, or should it be automagic? The code seems to be enumerating directories, and I seem to have multiple dirs under messages/ at least; anyone know a trick, or should I keep diagnosing? From Dan Mick Wed Aug 8 21:47:24 2001 From: Dan Mick (Dan Mick) Date: Wed, 8 Aug 2001 13:47:24 -0700 (PDT) Subject: [Mailman-Developers] Language selection in 2.1 Message-ID: <200108082047.NAA21887@utopia.West.Sun.COM> > Just CVSed to latest and installed a test machine. I only seem to get > 'en' showing up in the various web-interface dropdown boxes for available > languages or GUI-page translations. Is there some manual step to enable > other languages, or should it be automagic? The code seems to be enumerating > directories, and I seem to have multiple dirs under messages/ at least; > anyone know a trick, or should I keep diagnosing? Answering my own question with my own standard answer: "check out bin/". addlang looks like the trick (although its usage message still calls it "newlang"). Barry, where would you like such nit-bugs? barry@wooz.org? Sourceforge? Nowhere? :) From mrbill@mrbill.net Wed Aug 8 21:50:22 2001 From: mrbill@mrbill.net (Bill Bradford) Date: Wed, 8 Aug 2001 15:50:22 -0500 Subject: [Mailman-Developers] modifying list archives html? Message-ID: <20010808155022.H776@mrbill.net> Anybody know how to modify the default look of the HTML archives that mailman/pipermail produces? I'd like to add banner ads at the top of all the list archive pages... and a way to link back to the main page that hosts the lists. (ugh, I know, but I gotta pay the bills somehow..) Bill -- Bill Bradford mrbill@mrbill.net Austin, TX From Dan Mick Wed Aug 8 22:05:33 2001 From: Dan Mick (Dan Mick) Date: Wed, 8 Aug 2001 14:05:33 -0700 (PDT) Subject: [Mailman-Developers] modifying list archives html? Message-ID: <200108082105.OAA22865@utopia.West.Sun.COM> I think by hacking source, or using a third-party archiver that's more configurable. I just wish there were a third-party archiver that wrapped up the "start a new one monthly or weekly" or whatever without a bunch of custom cron hacks. > Anybody know how to modify the default look of the HTML archives > that mailman/pipermail produces? I'd like to add banner ads at > the top of all the list archive pages... and a way to link back to > the main page that hosts the lists. > > (ugh, I know, but I gotta pay the bills somehow..) From mailman@themargofoundation.org Thu Aug 9 15:31:43 2001 From: mailman@themargofoundation.org (Natambu Obleton) Date: Thu, 9 Aug 2001 08:31:43 -0600 Subject: [Mailman-Developers] PGP and Mailman Message-ID: <001d01c120e0$04a6fbe0$0804000a@newcent.com> I have seen a project on SourgeForge about a PGP addition to mailman. Is anyone working on this? I need to create this for a project I am working on and just don't want to reinvent if possible. :) From rodolfo@linux.org.uy Fri Aug 10 18:44:14 2001 From: rodolfo@linux.org.uy (Rodolfo Pilas) Date: Fri, 10 Aug 2001 14:44:14 -0300 Subject: [Mailman-Developers] Problem 2.1a2 with aliases.db n´Postfix Message-ID: <20010810144414.2f0e1175.rodolfo@linux.org.uy> I have explained my problem in mailman-users but I continue with the problem and my mail server is down now. For this reason I paste here my previous postings in mailman-users. I can not add new lists into mailman/data/aliases.db to be used by Postfix. I appreciate all of your possible help. And I can do all test or modifications that you suggest. ----- FIRST POSTING -------------------- Now I have problem with aliases.db file, and need help! I uses Postfix. README.POSTFIX says: - touch the file $mailman/data/aliases.db and make sure that both the owner and group-owner of the file is `mailman'. Make sure that both owner and group have read and write permission. see ls -al /var/spool/mailman/data/aliases.db -rw-rw-r-- 1 mailman mailman 0 Aug 9 06:07 aliases.db well, when I create a new list I receive the following error: Traceback (most recent call last): File "/usr/lib/mailman/scripts/driver", line 96, in run_main main() File "/usr/lib/mailman/Mailman/Cgi/create.py", line 54, in main process_request(doc, cgidata) File "/usr/lib/mailman/Mailman/Cgi/create.py", line 178, in process_request sys.modules[modname].create(mlist, cgi=1) File "/usr/lib/mailman/Mailman/MTA/Postfix.py", line 122, in create db = dbhash.open(DBFILE, 'c') File "/var/tmp/python-root//usr/lib/python2.0/dbhash.py", line 8, in open return bsddb.hashopen(file, flag, mode) error: (22, 'Invalid argument') I understand that problem is in the Postfix.py", line 122, in create db = dbhash.open(DBFILE, 'c') and is not a problem of Postfix daemon running as nobody:nobody. The aliases.db remains 0 byte but all other task are completed (the list can be listed and admin). Postfix says: postfix/local[19621]: fatal: open database /var/spool/mailman/data/aliases.db: Invalid argument postfix/qmgr[19291]: warning: end of input while receiving string data from service private/local postfix/qmgr[19291]: warning: private/local: malformed response postfix/master[19289]: warning: process /usr/lib/postfix/local pid 19621 exit status 1 postfix/master[19289]: warning: /usr/lib/postfix/local: bad command startup -- throttling Can somebody help me, please?? ------------ SECOND POSTING ---------------------- El Fri, 10 Aug 2001 11:16:25 -0400 Greg Ward ha escrito: > On 09 August 2001, Rodolfo Pilas said: > > see ls -al /var/spool/mailman/data/aliases.db > > > > -rw-rw-r-- 1 mailman mailman 0 Aug 9 06:07 aliases.db > Berkeley DB doesn't like zero-byte files. Despite what README.postfix > says, I would delete that aliases.db file and try again. I'm guessing > Mailman (or rather, the bsddb module) will create it for you. No way. I have made the following error when create a list: 1) I deleted aliases.db, as you suggest. -> Error! 2) I echo \# >> aliases.db (puaj!) -> Error! 3) I cp /etc/aliases.db mailman/data/aliases.db -> Error! See now the error of test 3): Traceback (most recent call last): File "./newlist", line 192, in ? main() File "./newlist", line 167, in main sys.modules[modname].create(mlist) File "/usr/lib/mailman/Mailman/MTA/Postfix.py", line 134, in create addlist(mlist, db, fp) File "/usr/lib/mailman/Mailman/MTA/Postfix.py", line 91, in addlist print >> fp, '# CREATED:', time.ctime() TypeError: function requires at least one argument Now I understand a problem in MTA/Postfix.py Perhaps I need to go to mailman-dev list with my problem... ------------------ -- ____________________________________________________ -=(( Rodolfo Pilas - rodolfo@linux.org.uy ))=- -==((( Are you ready for XtraLinuX - http://xtralinux.org )))==- -=((____________________________________________________))=- Guarde sus mail en Echelon: OLP, Greenpeace, ETA, Hamas, Hizbullah, FMI Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 From parris@isciences.com Fri Aug 10 19:59:29 2001 From: parris@isciences.com (Thomas M. Parris) Date: Fri, 10 Aug 2001 14:59:29 -0400 Subject: [Mailman-Developers] edit moderated messages? Message-ID: <002401c12114$6a7fafa0$3a28603f@CHERRYBLOSSOM> Dear mailman-developers: I recently sent the following query to mailman-users. I got once response suggesting that I edit the ~/data files directly (witth Xemacs), then warning of the obvious security issues, and ultimately recommending against such an approach. I'm willing to put some muscle into this feature, but have not programmed with Python before. So, 1. Can you tell me if anyone is currently working in implementing moderated edits? 2. If not, would you be willing to help me climb the learning curve to implement moderated edits myself? (I have programmed extensively in a numerous programming languages and am well versed in WWW/CGI programming. 3. Are there deep rooted philosophical objections to moderated edits? Here is the original query ... I am migrating a set of lists from CREN's listproc to mailman. So far, I am very impressed with mailman and have had no problems installing it (mailman-2.0.6) onto a RedHat 7.1 server with sendmail as the MTA. My heartfelt thanks to the mailman team for putting together such a fine product. However, there is one important feature from listproc that I am unable to replicate with mailman, the ability for list moderators to edit messages as part of the approval process. I can edit the message on the approval form, but the message is sent to the list without edits. I have checked the FAQ, the wish list, and the archives. I see some discussion of this as a "wish" in the developers list during 1999, and one or two messages in the last year or so on the users list. However, I see no indication that this feature has been implemented, or is being considered for implementation. For my application, the moderator must eb able to edit subject lines and the content of messages. 1. Am I blind? If so, I would be most grateful of someone could point me to some information about how to do this. 2. If it is not possible using the approval form, can someone suggest a work-around that would not be too cumbersome for a moderator that must approve/edit approximately 20-50 messages per day? With best regards, Tom Parris ------------------------------------------------------ Thomas M. Parris Research Scientist & Executive Director, Boston Office ISCIENCES, LLC 685 Centre Street, Suite 207 Jamaica Plain, MA 02130 voice: 617.524.8041 http://www.isciences.com/ fax: 509.463.4679 http://www.terraviva.net/ email: parris@isciences.com ------------------------------------------------------ ------------------------------------------------------ Mailman-Users maillist - Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users From claw@2wire.com Fri Aug 10 20:02:38 2001 From: claw@2wire.com (J C Lawrence) Date: Fri, 10 Aug 2001 12:02:38 -0700 Subject: [Mailman-Developers] edit moderated messages? In-Reply-To: Message from "Thomas M. Parris" of "Fri, 10 Aug 2001 14:59:29 EDT." <002401c12114$6a7fafa0$3a28603f@CHERRYBLOSSOM> References: <002401c12114$6a7fafa0$3a28603f@CHERRYBLOSSOM> Message-ID: <25623.997470158@2wire.com> On Fri, 10 Aug 2001 14:59:29 -0400 Thomas M Parris wrote: > 3. Are there deep rooted philosophical objections to moderated > edits? My only request is that such edited posts contain a custom header indicating that they are have been edited and are thus not identical to the submitted message. -- J C Lawrence )\._.,--....,'``. ---------(*) /, _.. \ _\ ;`._ ,. claw@kanga.nu `._.-(,_..'--(,_..'`-.;.' http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly From parris@isciences.com Sat Aug 11 00:19:59 2001 From: parris@isciences.com (Thomas M. Parris) Date: Fri, 10 Aug 2001 19:19:59 -0400 Subject: [Mailman-Developers] desired functionality for moderators Message-ID: <002401c12114$6a7fafa0$3a28603f@CHERRYBLOSSOM> Dear mailman-developers: I am beginning to think a bit more seriously about the moderator's interface to mailman. I see several issues with the web based interface for moderators. 1. moderator edits. If configured to do so, moderators should have the ability to edit messages. If they change the contents of the message, a short header should automatically be inserted that indicated the original message has been altered by the moderator. This seems fairly straight forward, and I might be willing to go out and by a Python book and do it. 2. html/rtf formatted text and attachments. The current web form does not help with messages that are submitted with html/rtf formatting or attachments. Despite repeated requests, my lists continue to get such submissions. I do not allow redistribution of such messages, but will often convert them to plain text as a service to my posters (most of whom are clueless). The only way to implement this would be do completely overhaul the web interface to be more like a webmail interface (something like hotmail), that actually renders the message (if it has html) and seperates out attachments for download. This is more than I can take on. I think see a fairly painless solution to both problems. 1. Offer a list option on moderated lists to automatically forward messages to the list moderator (possibly address(es)than the owner(s)). This would be the equivalent of a "Defer" coupled with a "forward this message to ..." so the code base should already exist. 2. The moderator can then send in the message after any necessary editing/format conversion. We could stop here, but then all moderated messages would appear to originate from the moderator. While some would no doubt ask for it, any solution that allowed the moderator to "spoof" the sender address back to the original poster would probably be a bad idea. Thoughts? -- Tom From rodolfo@linux.org.uy Sat Aug 11 00:19:51 2001 From: rodolfo@linux.org.uy (Rodolfo Pilas) Date: Fri, 10 Aug 2001 20:19:51 -0300 Subject: [Mailman-Developers] Problem 2.1a2 with aliases.db n´Postfix In-Reply-To: <20010810133405.R14293@mrbill.net> References: <20010810144414.2f0e1175.rodolfo@linux.org.uy> <20010810133405.R14293@mrbill.net> Message-ID: <20010810201951.1d07de0c.rodolfo@linux.org.uy> El Fri, 10 Aug 2001 13:34:05 -0500 Bill Bradford ha escrito: > On Fri, Aug 10, 2001 at 02:44:14PM -0300, Rodolfo Pilas wrote: > > I can not add new lists into > > mailman/data/aliases.db to be used by Postfix. > > Did you run "postalias > fp, '# CREATED:', time.ctime() TypeError: function requires at least one argument And the mailman/data/aliases contains this: # This file is generated by Mailman, and is kept in sync with the # binary hash file aliases.db. YOU SHOULD NOT MANUALLY EDIT THIS FILE # unless you know what you're doing, and can keep the two files properly # in sync. If you screw it up, you're on your own. # STANZA START: test3 # CREATED: Any other idea? I can test any suggestion. -- ____________________________________________________ -=(( Rodolfo Pilas - rodolfo@linux.org.uy ))=- -==((( Are you ready for XtraLinuX - http://xtralinux.org )))==- -=((____________________________________________________))=- Guarde sus mail en Echelon: OLP, Greenpeace, ETA, Hamas, Hizbullah, FMI Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 From thomas@xs4all.net Sat Aug 11 13:30:44 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Sat, 11 Aug 2001 14:30:44 +0200 Subject: [Mailman-Developers] Re: =?unknown-8bit?Q?=5BMailman-Developers?= =?unknown-8bit?Q?=5D_Problem_2=2E1a2_with_aliases=2Edb_n=B4Postfix?= In-Reply-To: <20010810201951.1d07de0c.rodolfo@linux.org.uy> References: <20010810144414.2f0e1175.rodolfo@linux.org.uy> <20010810133405.R14293@mrbill.net> <20010810201951.1d07de0c.rodolfo@linux.org.uy> Message-ID: <20010811143044.F874@xs4all.nl> On Fri, Aug 10, 2001 at 08:19:51PM -0300, Rodolfo Pilas wrote: > El Fri, 10 Aug 2001 13:34:05 -0500 > and obtain the following error: > Traceback (most recent call last): > File "/usr/lib/mailman/scripts/driver", line 96, in run_main > main() > File "/usr/lib/mailman/Mailman/Cgi/create.py", line 54, in main > process_request(doc, cgidata) > File "/usr/lib/mailman/Mailman/Cgi/create.py", line 178, in > process_request > sys.modules[modname].create(mlist, cgi=1) > File "/usr/lib/mailman/Mailman/MTA/Postfix.py", line 134, in create > addlist(mlist, db, fp) > File "/usr/lib/mailman/Mailman/MTA/Postfix.py", line 91, in addlist > print >> fp, '# CREATED:', time.ctime() > TypeError: function requires at least one argument Oh, oh, bad, bad Barry... another Python 2.1 feature used in Mailman ;) Will be fixed in CVS in a few minutes. You can fix it manually by changing 'time.ctime()' into 'time.ctime(time.time())'. Courtesy-of-HAL2001's-wireless-network-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From thomas@xs4all.net Sat Aug 11 13:42:24 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Sat, 11 Aug 2001 14:42:24 +0200 Subject: [Mailman-Developers] edit moderated messages? In-Reply-To: <002401c12114$6a7fafa0$3a28603f@CHERRYBLOSSOM> References: <002401c12114$6a7fafa0$3a28603f@CHERRYBLOSSOM> Message-ID: <20010811144224.G874@xs4all.nl> On Fri, Aug 10, 2001 at 02:59:29PM -0400, Thomas M. Parris wrote: > 1. Can you tell me if anyone is currently working in implementing moderated > edits? If I recall correctly (and I may not, mind you!) you could actually edit held messages in the moderator webinterface. I think it was removed to make the moderation stuff more reliable, as well as keeping the moderator admin page small(er) -- sending every message in full can generate very big forms. Old-timers should be able to confirm this, by the way ;P -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From rodolfo@linux.org.uy Sat Aug 11 17:18:45 2001 From: rodolfo@linux.org.uy (Rodolfo Pilas) Date: Sat, 11 Aug 2001 13:18:45 -0300 Subject: [Mailman-Developers] Problem 2.1a2 with aliases.db n´Postfix In-Reply-To: <20010811143044.F874@xs4all.nl> References: <20010810144414.2f0e1175.rodolfo@linux.org.uy> <20010810133405.R14293@mrbill.net> <20010810201951.1d07de0c.rodolfo@linux.org.uy> <20010811143044.F874@xs4all.nl> Message-ID: <20010811131845.097ac99b.rodolfo@linux.org.uy> El Sat, 11 Aug 2001 14:30:44 +0200 Thomas Wouters ha escrito: > On Fri, Aug 10, 2001 at 08:19:51PM -0300, Rodolfo Pilas wrote: > > El Fri, 10 Aug 2001 13:34:05 -0500 > You can fix it manually by changing > 'time.ctime()' into 'time.ctime(time.time())'. It's work!!! Thank you!! -- ____________________________________________________ -=(( Rodolfo Pilas - rodolfo@linux.org.uy ))=- -==((( Are you ready for XtraLinuX - http://xtralinux.org )))==- -=((____________________________________________________))=- Guarde sus mail en Echelon: OLP, Greenpeace, ETA, Hamas, Hizbullah, FMI Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 From claw@kanga.nu Sat Aug 11 17:16:50 2001 From: claw@kanga.nu (J C Lawrence) Date: Sat, 11 Aug 2001 09:16:50 -0700 Subject: [Mailman-Developers] edit moderated messages? In-Reply-To: Message from Thomas Wouters of "Sat, 11 Aug 2001 14:42:24 +0200." <20010811144224.G874@xs4all.nl> References: <002401c12114$6a7fafa0$3a28603f@CHERRYBLOSSOM> <20010811144224.G874@xs4all.nl> Message-ID: <6644.997546610@kanga.nu> On Sat, 11 Aug 2001 14:42:24 +0200 Thomas Wouters wrote: > If I recall correctly (and I may not, mind you!) you could > actually edit held messages in the moderator webinterface. I think > it was removed to make the moderation stuff more reliable, as well > as keeping the moderator admin page small(er) -- sending every > message in full can generate very big forms. Nope, never was supported, and if you look at the current setup the forms can be very large if ADMINDB_PAGE_TEXT_LIMIT is set large enough (I have mine set to 10Meg) and there are nough/large_enough held posts. -- J C Lawrence )\._.,--....,'``. ---------(*) /, _.. \ _\ ;`._ ,. claw@kanga.nu `._.-(,_..'--(,_..'`-.;.' http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly From trey@anvils.org Sun Aug 12 05:23:57 2001 From: trey@anvils.org (Trey Valenta) Date: Sat, 11 Aug 2001 21:23:57 -0700 Subject: [Mailman-Developers] PGP and Mailman In-Reply-To: "Natambu Obleton" "[Mailman-Developers] PGP and Mailman" (Aug 9, 8:31) Message-ID: <20010812042357.25799.qmail@zipcon.net> I haven't seen any replies to this question on the list, but I'm also interested in pgp encryption for the lists. /trey On 2001 Aug 9, 8:31, "Natambu Obleton" wrote: } Subject: [Mailman-Developers] PGP and Mailman > I have seen a project on SourgeForge about a PGP addition to mailman. Is > anyone working on this? I need to create this for a project I am working on > and just don't want to reinvent if possible. :) > }-- End of excerpt from "Natambu Obleton" -- trey valenta trey@anvils.org seattle (maybe a) random quote--v Learn to pause -- or nothing worthwhile can catch up to you. From ricardo@rixhq.nu Sun Aug 12 13:29:30 2001 From: ricardo@rixhq.nu (Ricardo F. Kustner) Date: Sun, 12 Aug 2001 14:29:30 +0200 Subject: [Mailman-Developers] edit moderated messages? In-Reply-To: <20010811144224.G874@xs4all.nl> References: <002401c12114$6a7fafa0$3a28603f@CHERRYBLOSSOM> <20010811144224.G874@xs4all.nl> Message-ID: <20010812142930.4a65c30a.ricardo@rixhq.nu> On Sat, 11 Aug 2001 14:42:24 +0200 Thomas Wouters wrote: > On Fri, Aug 10, 2001 at 02:59:29PM -0400, Thomas M. Parris wrote: > > 1. Can you tell me if anyone is currently working in implementing > moderated > > edits? > If I recall correctly (and I may not, mind you!) you could actually edit > held messages in the moderator webinterface. I think it was removed to > make > the moderation stuff more reliable, as well as keeping the moderator > admin > page small(er) -- sending every message in full can generate very big > forms. > Old-timers should be able to confirm this, by the way ;P *buzz* wrong :-) As for as I know, it was never an option... I should know cause I've spend a lot of time in admindb.py, as with every new release I had to put back my own small hacks. We *did* however discuss this a lot a while ago, which could explain why you think it was actually on there, but it never made it into the code, unless something is terribly with my memory (wouldn't surprise me though :)). Anyway maybe something for 2.1? Regards, Ricardo From barry@zope.com Mon Aug 13 04:50:25 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sun, 12 Aug 2001 23:50:25 -0400 Subject: [Mailman-Developers] Re: =?unknown-8bit?Q?=5BMailman-Developers?= =?unknown-8bit?Q?=5D_Problem_2=2E1a2_with_aliases=2Edb_n=B4Postfix?= References: <20010810144414.2f0e1175.rodolfo@linux.org.uy> <20010810133405.R14293@mrbill.net> <20010810201951.1d07de0c.rodolfo@linux.org.uy> <20010811143044.F874@xs4all.nl> Message-ID: <15223.20097.56330.438875@anthem.wooz.org> >>>>> "TW" == Thomas Wouters writes: TW> Oh, oh, bad, bad Barry... another Python 2.1 feature used in TW> Mailman ;) Will be fixed in CVS in a few minutes. You can fix TW> it manually by changing 'time.ctime()' into TW> 'time.ctime(time.time())'. Thanks for taking care of this Thomas! I was on a week's vacation so I'll be enjoying catching up on email for the next three. :) And yeah, I gotta keep testing this stuff on Python 2.0. hoping-mailman-2.1-beats-python-2.2-or-we'll-really-look-dumb-ly y'rs, -Barry From barry@zope.com Mon Aug 13 05:25:23 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 13 Aug 2001 00:25:23 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] postfix alias mailman 2.1a2 References: <20010810144414.2f0e1175.rodolfo@linux.org.uy> <3B5FDF00.C7F6244D@mercatis.de> Message-ID: <15223.22195.514236.437151@anthem.wooz.org> >>>>> "AH" == Armin Haaf writes: AH> I installed mailman 2.1a2 on suse 7.2 with postfix as MTA. It AH> works fine until I set postfix as MTA in mm_cfg.py. After that AH> a list creation gives the following message: | Traceback (most recent call last): | File "/home/mailman/app/mailman//scripts/driver", line 96, in run_main | main() | File "../Mailman/Cgi/create.py", line 54, in main | process_request(doc, cgidata) | File "../Mailman/Cgi/create.py", line 178, in process_request | sys.modules[modname].create(mlist, cgi=1) | File "../Mailman/MTA/Postfix.py", line 122, in create | db = dbhash.open(DBFILE, 'c') | File "/var/tmp/python-root//usr/lib/python2.0/dbhash.py", line 8, in | open | return bsddb.hashopen(file, flag, mode) | error: (22, 'Invalid argument') >>>>> "RP" == Rodolfo Pilas writes: RP> I have explained my problem in mailman-users but I continue RP> with the problem and my mail server is down now. For this RP> reason I paste here my previous postings in mailman-users. I RP> can not add new lists into mailman/data/aliases.db to be used RP> by Postfix. [same traceback] I'm not able to reproduce this particular crash. When I follow the directions in README.POSTFIX, everything works fine. Could we be hitting a library mismatch between the version of bsddb linked to Postfix and the one linked to Python? If so, that could make this approach fairly dicey. -Barry From barry@zope.com Mon Aug 13 05:37:09 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 13 Aug 2001 00:37:09 -0400 Subject: [Mailman-Developers] edit moderated messages? References: <002401c12114$6a7fafa0$3a28603f@CHERRYBLOSSOM> Message-ID: <15223.22901.532347.293564@anthem.wooz.org> [Trimming to mailman-developers... -BAW] >>>>> "TMP" == Thomas M Parris writes: TMP> 1. Can you tell me if anyone is currently working in TMP> implementing moderated edits? JC's right, this has never been supported. He also points out two other good things to keep in mind when thinking about working on this: 1) the edited message must (IMO) automatically include some kind of prominent disclaimer that it has been edited; 2) the current moderation interface doesn't include the entire message, and doing so could really bog down the admindb page. For #1, I definitely wouldn't want to bury the disclaimer in an X- header, which not all MUAs will display. Perhaps it's best to stick something in the footer or header, or modify the Subject: line. I'm not sure. A little bit of user testing would be in order. For #2, I can see two approaches. Either support only via-email editing, or reorganize the admindb page so that you can limit the total number of messages it displays (and thus the size of the page, even given some big messages). I've thought about including the original message in the first admin notification that gets sent when the message is held, probably as a MIME attachment. I've also thought about including /all/ the held messages as MIME attachements for the daily admin notifications. Ideal would be a way to respond to a MIME digested message such that you could inform Mailman of the action you want to take on it. Since I think discard is probably the most common action, that one should be the least painful, but all other options should be possible. Unfortunately, I haven't come up with a decent email-based UI that wouldn't be error prone. Alternatively, we could simplify the "forward to admin" feature of the admindb page. Then the admin could edit the message and resend it (i.e. using Resent-to:). TMP> 2. If not, would you be willing to help me climb the learning TMP> curve to implement moderated edits myself? (I have TMP> programmed extensively in a numerous programming languages TMP> and am well versed in WWW/CGI programming. It would be cool to have folks work out some of these issues, but I don't think I will have time for the MM2.1 release. I'd really like to get to feature freeze soon, so I'd prefer an approach where you folks prototype and test out some of the stickier ui issues. TMP> 3. Are there deep rooted philosophical objections to TMP> moderated edits? Not as long as the recipients are clearly informed that the message has been edited by the moderator. -Barry From chuqui@plaidworks.com Mon Aug 13 06:17:54 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Sun, 12 Aug 2001 22:17:54 -0700 Subject: [Mailman-Developers] edit moderated messages? In-Reply-To: <15223.22901.532347.293564@anthem.wooz.org> Message-ID: On 8/12/01 9:37 PM, "Barry A. Warsaw" wrote: > For #1, I definitely wouldn't want to bury the disclaimer in an X- > header, which not all MUAs will display. Perhaps it's best to stick > something in the footer or header, or modify the Subject: line. I'm > not sure. A little bit of user testing would be in order. Not an x-header, definitely. And I think putting it in the subject line is wrong, also. I'd suggest simply putting a [message edited by moderator] in line 1 of the message body. > For #2, I can see two approaches. Either support only via-email > editing, or reorganize the admindb page so that you can limit the > total number of messages it displays (and thus the size of the page, > even given some big messages). Add another button -- "edit", which brings up a page where you can edit that message, when when you save it, takes you back to the current admindb page. You'd have to worry about state on other messages (if you have already clicked discard or approve, you don't want to lose it), but otherwise, it's pretty straight forward. -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. I'm out of my mind, but feel free to leave a message... From barry@zope.com Mon Aug 13 06:32:31 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 13 Aug 2001 01:32:31 -0400 Subject: [Mailman-Developers] edit moderated messages? References: <15223.22901.532347.293564@anthem.wooz.org> Message-ID: <15223.26223.22598.753105@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: CVR> Not an x-header, definitely. And I think putting it in the CVR> subject line is wrong, also. CVR> I'd suggest simply putting a [message edited by moderator] in CVR> line 1 of the message body. Good idea. >> For #2, I can see two approaches. Either support only >> via-email editing, or reorganize the admindb page so that you >> can limit the total number of messages it displays (and thus >> the size of the page, even given some big messages). CVR> Add another button -- "edit", which brings up a page where CVR> you can edit that message, when when you save it, takes you CVR> back to the current admindb page. You'd have to worry about CVR> state on other messages (if you have already clicked discard CVR> or approve, you don't want to lose it), but otherwise, it's CVR> pretty straight forward. Another good idea. Given that this button probably shouldn't pop up a new browser window, we can make sure that the "Submit" or "Cancel" button on the edit window returns you back to the big admindb page, with the state updated. Note that the admin "details" pages have a similar problem. If you pop them up in a new window, you're responsible for keeping things in sync. This might not be too hard to add for 2.1. -Barry From claw@kanga.nu Mon Aug 13 07:15:15 2001 From: claw@kanga.nu (J C Lawrence) Date: Sun, 12 Aug 2001 23:15:15 -0700 Subject: [Mailman-Developers] edit moderated messages? In-Reply-To: Message from barry@zope.com (Barry A. Warsaw) of "Mon, 13 Aug 2001 00:37:09 EDT." <15223.22901.532347.293564@anthem.wooz.org> References: <002401c12114$6a7fafa0$3a28603f@CHERRYBLOSSOM> <15223.22901.532347.293564@anthem.wooz.org> Message-ID: <30915.997683315@kanga.nu> On Mon, 13 Aug 2001 00:37:09 -0400 Barry A Warsaw wrote: > [Trimming to mailman-developers... -BAW] Thanks. >>>>>> "TMP" == Thomas M Parris writes: TMP> 1. Can you tell me if anyone is currently working in TMP> implementing moderated edits? > JC's right, this has never been supported. He also points out two > other good things to keep in mind when thinking about working on > this: 1) the edited message must (IMO) automatically include some > kind of prominent disclaimer that it has been edited; 2) the > current moderation interface doesn't include the entire message, > and doing so could really bog down the admindb page. I have ADMINDB_PAGE_TEXT_LIMIT set to 10Meg IIRC, and yes, it does make admin pages slow when there is a significant moderation queue, and yes, I'm on a fast connection. I consider this necessary however as I require being able to read the entire message in the moderation queue and not just an excerpt. > For #1, I definitely wouldn't want to bury the disclaimer in an X- > header, which not all MUAs will display. Perhaps it's best to > stick something in the footer or header, or modify the Subject: > line. I'm not sure. A little bit of user testing would be in > order. An X-header seems the absolute minimum. A in-message text blob (possibly in addition to the X-header) seems about the maximum. There seems little reason not to support either option on a per-list config basis ala: [textarea] Add the above text above the message contents on any message edited by the moderation interface? And then add a check box to the moderation interface to suppress this added text blob on a per-message basis (in the group with preserve_message and forward_message_to). This would leave the X-header in place, but not flag the message more explicitly. This would be useful when correcting minor typoes and the like which don't actually change semantic content. > For #2, I can see two approaches. Either support only via-email > editing... Email-based moderation would be a Good Thing, both at the approve/reject/discard command level, and at the approve_with_edits level. Aside. I haven't checked if the current beta does this, but rejection messages should have the entire rejected message as a message/rfc822 part. The current business of sending nothing but the rejection comment back to the poster is causing me considerable pain. > ... or reorganize the admindb page so that you can limit the total > number of messages it displays (and thus the size of the page, > even given some big messages). Given spam and mail loops, this seems a generally Good Thing, no matter the cause. > I've thought about including the original message in the first > admin notification that gets sent when the message is held, > probably as a MIME attachment. I'd vote for that. > I've also thought about including /all/ the held messages as MIME > attachements for the daily admin notifications. I'd vote for that as a configurable option. > Ideal would be a way to respond to a MIME digested message such > that you could inform Mailman of the action you want to take on > it. Since I think discard is probably the most common action... No, "defer" should be, just as it is now. You want the default to be safe, and the likely actions to be trivially easy. > ... that one should be the least painful, but all other options > should be possible. Unfortunately, I haven't come up with a > decent email-based UI that wouldn't be error prone. You realise that the next step will be magic-URL based individual moderation queue message manipulation don't you? > Alternatively, we could simplify the "forward to admin" feature of > the admindb page. Then the admin could edit the message and > resend it (i.e. using Resent-to:). -- J C Lawrence )\._.,--....,'``. ---------(*) /, _.. \ _\ ;`._ ,. claw@kanga.nu `._.-(,_..'--(,_..'`-.;.' http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly From claw@kanga.nu Mon Aug 13 07:19:11 2001 From: claw@kanga.nu (J C Lawrence) Date: Sun, 12 Aug 2001 23:19:11 -0700 Subject: [Mailman-Developers] edit moderated messages? In-Reply-To: Message from Chuq Von Rospach of "Sun, 12 Aug 2001 22:17:54 PDT." References: Message-ID: <30932.997683551@kanga.nu> On Sun, 12 Aug 2001 22:17:54 -0700 Chuq Von Rospach wrote: > Not an x-header, definitely. Why not? I can see why not exclusively, but why not in general? > And I think putting it in the subject line is wrong, also. Agreed. > I'd suggest simply putting a [message edited by moderator] in line > 1 of the message body. I have a slight problem: For one of my lists I edit every single message. I reflow/wrap quotes and text to margins, I respace quotes characters, I trim attributions and signatures, I collapse TABs, etc. In the vast majority of cases I don't actually change the text, other than its formatting, at all. In those cases while I wouldn't mind the X-Header, I would mind the in-message blob. Conversely, I would and do want the in-message blob when I do larger edits ala quote trimming, large text editing/removal, etc. >> For #2, I can see two approaches. Either support only via-email >> editing, or reorganize the admindb page so that you can limit the >> total number of messages it displays (and thus the size of the >> page, even given some big messages). > Add another button -- "edit", which brings up a page where you can > edit that message, when when you save it, takes you back to the > current admindb page. You'd have to worry about state on other > messages (if you have already clicked discard or approve, you > don't want to lose it), but otherwise, it's pretty straight > forward. I like. -- J C Lawrence )\._.,--....,'``. ---------(*) /, _.. \ _\ ;`._ ,. claw@kanga.nu `._.-(,_..'--(,_..'`-.;.' http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly From chuqui@plaidworks.com Mon Aug 13 07:26:54 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Sun, 12 Aug 2001 23:26:54 -0700 Subject: [Mailman-Developers] sendmail In-Reply-To: <5.1.0.14.2.20010803211659.04297e20@lennier.cc.vt.edu> Message-ID: On 8/3/01 6:46 PM, "Ron Jarrell" wrote: > > Ok, if anyone else running sendmail would like to test this a bit, > I'd appreciate it. You need to be running at least 8.11 I believe. > (And if you're running 8.11, you ought to be at 8.11.4) Okay, I've had a chance to test this, and tweak it a bit. Sorry for the delay in responding -- I moved ISPs this last week, and the dust is just settling. I did this a little differently, since I know that tweaking sendmail.cf files gives many people hives, and so people aren't likely to do it. It's also unneccesary. You can do this without modifying your sendmail files at all. Instead, in your startup script, add: /usr/sbin/sendmail -bd -ODeliveryMode=defer \ -ODaemonPortOptions=Name=MSA,Port=NNNN,M=E,Addr=127.0.0.1 Where NNNN is some port number not otherwise used (you can test if something's in use by doing "telnet localhost NNNN" -- if it's refused, there's no daemon listening) This sets up a sendmail process listening to the alternate port, in DEFER mode, but set to talk only to the localhost interface, so it's not accessible by anyoneother than your local machine: no open relay problems. To make mailman access that port, add this to your mm_cfg.py: # define alternate SMTP port SMTPPORT = 1313 I've been running this fine for about a week, and I'm quite comfortable with it. It works with sendmail 8.10 and later and doesn't require a sendmail god to implement. Ready for the FAQ, I'd say. Chuq -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. Love is the process of my leading you gently back to yourself. - Saint Exupery From chuqui@plaidworks.com Mon Aug 13 07:30:48 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Sun, 12 Aug 2001 23:30:48 -0700 Subject: [Mailman-Developers] edit moderated messages? In-Reply-To: <30932.997683551@kanga.nu> Message-ID: On 8/12/01 11:19 PM, "J C Lawrence" wrote: > On Sun, 12 Aug 2001 22:17:54 -0700 > Chuq Von Rospach wrote: > >> Not an x-header, definitely. > > Why not? I can see why not exclusively, but why not in general? Because most users don't have a clue they exist, and most that do don't think to look. As far as I'm concerned, X-headers are useful only to talk to a program that's looking to read them. Using them to communicate to an end-user is a failure. > I have a slight problem: For one of my lists I edit every single > message. In this special case,I'd suggest you hack the code to omit the message. I do not, however, think it's a good idea to omit the message, or make the message configurable in some way -- because I think users need to be warned (this is a case where it's a standard operation for the list, so it's Different), and I think removing that message should be diffifcult and an overt act, not something configured with half a thought. -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. USENET is a lot better after two or three eggnogs. We shouldn't allow anyone on the net without a bottle of brandy. (chuq von rospach, 1992) From Dale Newfield Mon Aug 13 14:11:02 2001 From: Dale Newfield (Dale Newfield) Date: Mon, 13 Aug 2001 09:11:02 -0400 (EDT) Subject: [Mailman-Developers] edit moderated messages? In-Reply-To: Message-ID: On Sun, 12 Aug 2001, Chuq Von Rospach wrote: > In this special case,I'd suggest you hack the code to omit the message. If the blob is added to the message when someone hits the "Edit" button, then they can as part of the edits remove it... -Dale From parris@isciences.com Mon Aug 13 15:00:16 2001 From: parris@isciences.com (Thomas M. Parris) Date: Mon, 13 Aug 2001 10:00:16 -0400 Subject: [Mailman-Developers] edit moderated messages? In-Reply-To: Message-ID: <001201c12400$487c4c30$3a28603f@CHERRYBLOSSOM> I'm impressed by the level of attention you are all giving to this. Here are my thoughts. 1. admin page moderation I like the idea of a button to bring up the entire message in an editable text box. However, this would only work for plan text messages. It would not work for those *@&^#*&! messages with embedded html/rtf markup. It would also be problematic for messages with attachments (e.g., word processing files, PDF's, and the like). Adequately addressing these two issues would require a lot of development work (the equivalent of constructing a full web-based mail interface). 2. email based moderation This strikes me as a good solution. Detecting edits (for insertion of the notification phrase) would require some checksums. Having all of the messages as part of the message and daily notification messages would be convenient. 3. simplified forwarding the to list administrator. This would solve my immediate problem and require little additional development. Indeed, my current work around is to "discard" and "foward" to an approved address off of the web interface. Automating this with a "per-list" configuration option would simplify things greatly. The only downside is that all messages appear to come from the administrator address as opposed to the original sender. This is probably appropriate since this option is intended to allow the administrator to change the message. Eqtiquette then requires that the original poster be recognized in the body of the message. I usually do this by including the original "From:", "Date:" and "Subject:" headers. Best regards, Tom From jarrell@vt.edu Mon Aug 13 14:47:36 2001 From: jarrell@vt.edu (Ron Jarrell) Date: Mon, 13 Aug 2001 09:47:36 -0400 Subject: [Mailman-Developers] sendmail In-Reply-To: References: <5.1.0.14.2.20010803211659.04297e20@lennier.cc.vt.edu> Message-ID: <5.1.0.14.2.20010813094258.0261da70@lennier.cc.vt.edu> At 11:26 PM 8/12/01 -0700, Chuq Von Rospach wrote: >On 8/3/01 6:46 PM, "Ron Jarrell" wrote: > >> >> Ok, if anyone else running sendmail would like to test this a bit, >> I'd appreciate it. You need to be running at least 8.11 I believe. >> (And if you're running 8.11, you ought to be at 8.11.4) > >Okay, I've had a chance to test this, and tweak it a bit. Sorry for the >delay in responding -- I moved ISPs this last week, and the dust is just >settling. > >I did this a little differently, since I know that tweaking sendmail.cf >files gives many people hives, and so people aren't likely to do it. It's >also unneccesary. > >You can do this without modifying your sendmail files at all. Instead, in >your startup script, add: > > /usr/sbin/sendmail -bd -ODeliveryMode=defer \ > -ODaemonPortOptions=Name=MSA,Port=NNNN,M=E,Addr=127.0.0.1 > >Where NNNN is some port number not otherwise used (you can test if >something's in use by doing "telnet localhost NNNN" -- if it's refused, >there's no daemon listening) > >This sets up a sendmail process listening to the alternate port, in DEFER >mode, but set to talk only to the localhost interface, so it's not >accessible by anyoneother than your local machine: no open relay problems. > >To make mailman access that port, add this to your mm_cfg.py: > ># define alternate SMTP port >SMTPPORT = 1313 > > >I've been running this fine for about a week, and I'm quite comfortable with >it. It works with sendmail 8.10 and later and doesn't require a sendmail god >to implement. Ready for the FAQ, I'd say. Well, if you go with this model, it needs to be mentioned that by operating in defer mode you're guaranteeing that outbound mail will be batched up, and not processed any faster than your queue running process is set to, which needs to be mentioned in the faq. My method, while requiring a change to the m4 file (which, granted, not everyone tweaks, although they really should) allows you to continue running in "realtime". There are no weird changes required unless you want to implement auto-aliasing, at which point you have to either blindly follow directions, or be at least a Junior Guru... From chuqui@plaidworks.com Mon Aug 13 15:41:20 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 13 Aug 2001 07:41:20 -0700 Subject: [Mailman-Developers] edit moderated messages? In-Reply-To: Message-ID: On 8/13/01 6:11 AM, "Dale Newfield" wrote: > On Sun, 12 Aug 2001, Chuq Von Rospach wrote: >> In this special case,I'd suggest you hack the code to omit the message. > > If the blob is added to the message when someone hits the "Edit" button, > then they can as part of the edits remove it... I wouldn't do that. I'd add it when the submit button is hit. Again, I think it's important for the subscriber to know the message was edited, so making it easy for that message to be removed is a bad idea. JC has a speciial case, wher eit's know that every message is tweaked, but we sholdn't make it easy for editing to be done without notification. -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. I'm really easy to get along with once you people learn to worship me. From chuqui@plaidworks.com Mon Aug 13 15:44:02 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 13 Aug 2001 07:44:02 -0700 Subject: [Mailman-Developers] sendmail In-Reply-To: <5.1.0.14.2.20010813094258.0261da70@lennier.cc.vt.edu> Message-ID: On 8/13/01 6:47 AM, "Ron Jarrell" wrote: > Well, if you go with this model, it needs to be mentioned that by operating in > defer mode you're guaranteeing that outbound mail will be batched up, and > not processed any faster than your queue running process is set to, which > needs to be mentioned in the faq. Good point. That's how I run all my systems anyway, so I'd forgotten that. (why? Load management) > There are no weird changes > required unless you want to implement auto-aliasing, at which point you have > to either blindly follow directions, or be at least a Junior Guru... To 99% of the unknown universe, LOOKING at a sendmail.cf file constitutes a weird change. -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. I tried to get a life once, but they were out of stock. From rodolfo@linux.org.uy Mon Aug 13 17:47:07 2001 From: rodolfo@linux.org.uy (Rodolfo Pilas) Date: Mon, 13 Aug 2001 13:47:07 -0300 Subject: [Mailman-Developers] Re: [Mailman-Users] postfix alias mailman 2.1a2 In-Reply-To: <15223.22195.514236.437151@anthem.wooz.org> References: <20010810144414.2f0e1175.rodolfo@linux.org.uy> <3B5FDF00.C7F6244D@mercatis.de> <15223.22195.514236.437151@anthem.wooz.org> Message-ID: <20010813134707.05eb9fa7.rodolfo@linux.org.uy> --=.N_5UoWx7r8_ZC0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit El Mon, 13 Aug 2001 00:25:23 -0400 barry@zope.com (Barry A. Warsaw) ha escrito: > I'm not able to reproduce this particular crash. When I follow the > directions in README.POSTFIX, everything works fine. Could we be > hitting a library mismatch between the version of bsddb linked to > Postfix and the one linked to Python? If so, that could make this > approach fairly dicey. Well, I fix the problem with these commands: 1) touch mailman/data/aliases (give the file the gid and access as README.POSTFIX) 2) postalias hash:mailman/data/aliases (this command creates an aliases.db) There is another problem in Mailman/MTA/Postfix.py with the function time.ctime() which requires a parameter in Python 2.0 but not in 2.1. The CVS has been fixed by Thomas Wouters but the file (of 2.1a2) can be fixed with time.ctime(time.time()) , as Thomas explained me. Because I run postfix as nobody:nogroup I need to configure mailman with --with-mail-gid=nogroup as a difference of README.POSTFIX said. Now I have all system working. An I wish to thank all of the help received in mailman-users and mailman-developers lists. THANK YOU! -- ____________________________________________________ -=(( Rodolfo Pilas - rodolfo@linux.org.uy ))=- -==((( Are you ready for XtraLinuX - http://xtralinux.org )))==- -=((____________________________________________________))=- Guarde sus mail en Echelon: OLP, Greenpeace, ETA, Hamas, Hizbullah, FMI Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 --=.N_5UoWx7r8_ZC0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7eASU0SDHc1cVM2MRAhqMAJ41o/KSA4TBh5sZ9WxRPFhFIYBE4gCgisvE cD5bhcZkQxO1ZRjRXnoEvs0= =NuoP -----END PGP SIGNATURE----- --=.N_5UoWx7r8_ZC0-- From jon@latchkey.com Mon Aug 13 19:14:22 2001 From: jon@latchkey.com (Jon Stevens) Date: Mon, 13 Aug 2001 11:14:22 -0700 Subject: [Mailman-Developers] sendmail In-Reply-To: Message-ID: on 8/13/01 7:44 AM, "Chuq Von Rospach" wrote: > To 99% of the unknown universe, LOOKING at a sendmail.cf file constitutes a > weird change. That's why I switched to postfix. :-) -jon (who, for *years* happily hacked .mc files and then realized it was a complete waste of time when he tried postfix out) From mrbill@mrbill.net Mon Aug 13 19:15:13 2001 From: mrbill@mrbill.net (Bill Bradford) Date: Mon, 13 Aug 2001 13:15:13 -0500 Subject: [Mailman-Developers] pending list submissions suggestion Message-ID: <20010813131513.U17023@mrbill.net> Any chance of a "review pending list submissions for all lists on this machine" function? I'm the sole admin for about 5-6 lists on my box, and logging in for each list to approve/deny posts is a pain sometimes.. Bill -- Bill Bradford mrbill@mrbill.net Austin, TX From mentor@alb-net.com Mon Aug 13 20:11:20 2001 From: mentor@alb-net.com (Mentor Cana) Date: Mon, 13 Aug 2001 15:11:20 -0400 (EDT) Subject: [Mailman-Developers] sendmail In-Reply-To: Message-ID: On Mon, 13 Aug 2001, at 11:14 -0700, Jon Stevens wrote: > on 8/13/01 7:44 AM, "Chuq Von Rospach" wrote: > > > To 99% of the unknown universe, LOOKING at a sendmail.cf file constitutes a > > weird change. > > That's why I switched to postfix. :-) Same here :) -- mentor From claw@2wire.com Mon Aug 13 20:17:45 2001 From: claw@2wire.com (J C Lawrence) Date: Mon, 13 Aug 2001 12:17:45 -0700 Subject: [Mailman-Developers] edit moderated messages? In-Reply-To: Message from "Thomas M. Parris" of "Mon, 13 Aug 2001 10:00:16 EDT." <001201c12400$487c4c30$3a28603f@CHERRYBLOSSOM> References: <001201c12400$487c4c30$3a28603f@CHERRYBLOSSOM> Message-ID: <18444.997730265@2wire.com> On Mon, 13 Aug 2001 10:00:16 -0400 Thomas M Parris wrote: > 1. admin page moderation I like the idea of a button to bring up > the entire message in an editable text box. However, this would > only work for plan text messages. It would not work for those > *@&^#*&! messages with embedded html/rtf markup. I'd count the fact that such a edit interface would display the raw MIME contents as an advantage. Among other things it would make manual removal and editing of specific MIME parts easy (eg changing quoted-printable to text/plain, application/octet-stream to image/jpeg, manual removal of vcards, text/html etc). > It would also be problematic for messages with attachments (e.g., > word processing files, PDF's, and the like). Adequately > addressing these two issues would require a lot of development > work (the equivalent of constructing a full web-based mail > interface). You can go a long way down that road if you really want to, which likely isn't really interesting for Mailman. But, there's attractive value to be gained in the first few steps as above which makes at least small motions interesting. -- J C Lawrence )\._.,--....,'``. ---------(*) /, _.. \ _\ ;`._ ,. claw@kanga.nu `._.-(,_..'--(,_..'`-.;.' http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly From claw@2wire.com Mon Aug 13 20:27:33 2001 From: claw@2wire.com (J C Lawrence) Date: Mon, 13 Aug 2001 12:27:33 -0700 Subject: [Mailman-Developers] edit moderated messages? In-Reply-To: Message from Chuq Von Rospach of "Sun, 12 Aug 2001 23:30:48 PDT." References: Message-ID: <18559.997730853@2wire.com> On Sun, 12 Aug 2001 23:30:48 -0700 Chuq Von Rospach wrote: > On 8/12/01 11:19 PM, "J C Lawrence" wrote: >> On Sun, 12 Aug 2001 22:17:54 -0700 Chuq Von Rospach >> wrote: >>> Not an x-header, definitely. >> Why not? I can see why not exclusively, but why not in general? > Because most users don't have a clue they exist, and most that do > don't think to look. As far as I'm concerned, X-headers are useful > only to talk to a program that's looking to read them. Using them > to communicate to an end-user is a failure. In which case, given that we can also add in-message blurbs, why not also have an X-header? This seems especially pertinent to those cases where the modification blurb is not only unnecessary, but is unwanted on a per-list basis. Its easy to view moderation editing only from a discussion list vantage. There are many other list types. For instance an announcement list where the moderator adds or updates canned branding data for list messages which are submitted by various product depts would explicitly NOT want the blurb for THAT list, but may well want it for other discussion lists on that same server. >> I have a slight problem: For one of my lists I edit every single >> message. > In this special case,I'd suggest you hack the code to omit the > message. That impacts all lists, not just the one or two lists I'm interested in. > I do not, however, think it's a good idea to omit the message, or > make the message configurable in some way -- because I think users > need to be warned (this is a case where it's a standard operation > for the list, so it's Different), and I think removing that > message should be diffifcult and an overt act, not something > configured with half a thought. I generically agree that the blurb should be there by default. I also agree that special action should be required to remove it. Unlike list-* headers, I don't see value in holding a hard line here. -- J C Lawrence )\._.,--....,'``. ---------(*) /, _.. \ _\ ;`._ ,. claw@kanga.nu `._.-(,_..'--(,_..'`-.;.' http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly From chuqui@plaidworks.com Mon Aug 13 20:32:30 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 13 Aug 2001 12:32:30 -0700 Subject: [Mailman-Developers] edit moderated messages? In-Reply-To: <18559.997730853@2wire.com> Message-ID: On 8/13/01 12:27 PM, "J C Lawrence" wrote: > In which case, given that we can also add in-message blurbs, why not > also have an X-header? No problem to me. I'm not sure what it buys us, but I'm not against it. -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. The Pinball Machine Rule is the observation that it doesn't matter a wit if the instructions are printed clearly for all to see, nobody will read them. They'll just drop their quarter(s) and start pushing buttons like a Tommy. -- Barry Warsaw From claw@2wire.com Mon Aug 13 20:41:22 2001 From: claw@2wire.com (J C Lawrence) Date: Mon, 13 Aug 2001 12:41:22 -0700 Subject: [Mailman-Developers] edit moderated messages? In-Reply-To: Message from Chuq Von Rospach of "Mon, 13 Aug 2001 12:32:30 PDT." References: Message-ID: <18881.997731682@2wire.com> On Mon, 13 Aug 2001 12:32:30 -0700 Chuq Von Rospach wrote: > On 8/13/01 12:27 PM, "J C Lawrence" wrote: >> In which case, given that we can also add in-message blurbs, why >> not also have an X-header? > No problem to me. I'm not sure what it buys us, but I'm not > against it. In certain business cases, I'd filter on it and then archive the message and its diff for liability/audit tracking purposes. -- J C Lawrence )\._.,--....,'``. ---------(*) /, _.. \ _\ ;`._ ,. claw@kanga.nu `._.-(,_..'--(,_..'`-.;.' http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly From alaric@babcom.com Mon Aug 13 21:43:34 2001 From: alaric@babcom.com (Phil Stracchino) Date: Mon, 13 Aug 2001 13:43:34 -0700 Subject: [Mailman-Developers] sendmail In-Reply-To: ; from mentor@alb-net.com on Mon, Aug 13, 2001 at 03:11:20PM -0400 References: Message-ID: <20010813134334.B12558@babylon5.babcom.com> On Mon, Aug 13, 2001 at 03:11:20PM -0400, Mentor Cana wrote: > On Mon, 13 Aug 2001, at 11:14 -0700, Jon Stevens wrote: > > on 8/13/01 7:44 AM, "Chuq Von Rospach" wrote: > > > To 99% of the unknown universe, LOOKING at a sendmail.cf file constitutes a > > > weird change. > > > > That's why I switched to postfix. :-) > > Same here :) So did I. But ... The pain??? What will I do without the pain??? :) -- Linux Now! ..........Because friends don't let friends use Microsoft. phil stracchino -- the renaissance man -- mystic zen biker geek alaric@babcom.com halmayne@sourceforge.net 2000 CBR929RR, 1991 VFR750F3 (foully murdered), 1986 VF500F (sold) From chuqui@plaidworks.com Mon Aug 13 21:47:29 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 13 Aug 2001 13:47:29 -0700 Subject: [Mailman-Developers] sendmail In-Reply-To: <20010813134334.B12558@babylon5.babcom.com> Message-ID: On 8/13/01 1:43 PM, "Phil Stracchino" wrote: >>> That's why I switched to postfix. :-) >> >> Same here :) > > > So did I. But ... The pain??? What will I do without the pain??? Not everyone has that option, though. So do you plan to simply laugh at those that can't? Me, I'm switching to postfix -- very slowly and carefully. Because I can't afford to break things. To me, the MTA is like the transmission of the bus, which is already full of kids I'm about to drive to summer camp. And I don't know about you, I have no intention of swapping out transmissions until I know I won't end up on the side of the road praying for a tow truck.... -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. When an agnostic dies, does he go to the "great perhaps"? From jharris@fourhorsemen.org Mon Aug 13 21:39:32 2001 From: jharris@fourhorsemen.org (jharris) Date: Mon, 13 Aug 2001 13:39:32 -0700 (PDT) Subject: [Mailman-Developers] archive handling Message-ID: I am new to the list, and pre apploigze for bringing up old ideas, but I was unable to find any discussion on this topic. Im running a list where several of the users like to post attachements. This isnt a problem except it tends to make the archives rather large and unslighlty. I wanted to know to know the current state of the rewrite mentioned on the current webpage. A simple option to remove attachements or even better convert them to links for the archive is what Im looking for. Im about to start implementing this myself, and just wanted to know if others are working on something similar such that we could combine efforts. From rodolfo@linux.org.uy Mon Aug 13 22:47:05 2001 From: rodolfo@linux.org.uy (Rodolfo Pilas) Date: Mon, 13 Aug 2001 18:47:05 -0300 Subject: [Mailman-Developers] Problem in cron task Message-ID: <20010813184705.006957ef.rodolfo@linux.org.uy> I have 2.1a2 with Python 2.0 in a SuSE 7.2 and receiving the following email: Subject: Cron /usr/bin/python -S /usr/lib/mailman/cron/nightly_gzip Traceback (most recent call last): File "/usr/lib/mailman/cron/nightly_gzip", line 52, in ? from Mailman import MailList File "/usr/lib/mailman/Mailman/MailList.py", line 34, in ? from mimelib.address import getaddresses ImportError: No module named mimelib.address But I installed mimelib and you can see here: guru:~ # locate mimelib /usr/lib/python2.0/site-packages/mimelib /usr/lib/python2.0/site-packages/mimelib/address.py /usr/lib/python2.0/site-packages/mimelib/address.pyc /usr/lib/python2.0/site-packages/mimelib/date.py /usr/lib/python2.0/site-packages/mimelib/date.pyc /usr/lib/python2.0/site-packages/mimelib/Errors.py /usr/lib/python2.0/site-packages/mimelib/Errors.pyc /usr/lib/python2.0/site-packages/mimelib/Generator.py /usr/lib/python2.0/site-packages/mimelib/Generator.pyc /usr/lib/python2.0/site-packages/mimelib/Image.py /usr/lib/python2.0/site-packages/mimelib/Image.pyc /usr/lib/python2.0/site-packages/mimelib/Message.py /usr/lib/python2.0/site-packages/mimelib/Message.pyc /usr/lib/python2.0/site-packages/mimelib/MIMEBase.py /usr/lib/python2.0/site-packages/mimelib/MIMEBase.pyc /usr/lib/python2.0/site-packages/mimelib/MsgReader.py /usr/lib/python2.0/site-packages/mimelib/MsgReader.pyc /usr/lib/python2.0/site-packages/mimelib/Parser.py /usr/lib/python2.0/site-packages/mimelib/Parser.pyc /usr/lib/python2.0/site-packages/mimelib/RFC822.py /usr/lib/python2.0/site-packages/mimelib/RFC822.pyc /usr/lib/python2.0/site-packages/mimelib/StringableMixin.py /usr/lib/python2.0/site-packages/mimelib/StringableMixin.pyc /usr/lib/python2.0/site-packages/mimelib/Text.py /usr/lib/python2.0/site-packages/mimelib/Text.pyc /usr/lib/python2.0/site-packages/mimelib/__init__.py /usr/lib/python2.0/site-packages/mimelib/__init__.pyc How I can fix this problem ?? -- ____________________________________________________ -=(( Rodolfo Pilas - rodolfo@linux.org.uy ))=- -==((( Are you ready for XtraLinuX - http://xtralinux.org )))==- -=((____________________________________________________))=- Guarde sus mail en Echelon: OLP, Greenpeace, ETA, Hamas, Hizbullah, FMI Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 From jon@latchkey.com Tue Aug 14 01:05:12 2001 From: jon@latchkey.com (Jon Stevens) Date: Mon, 13 Aug 2001 17:05:12 -0700 Subject: [Mailman-Developers] sendmail In-Reply-To: Message-ID: on 8/13/01 1:47 PM, "Chuq Von Rospach" wrote: > Not everyone has that option, though. So do you plan to simply laugh at > those that can't? > > Me, I'm switching to postfix -- very slowly and carefully. Because I can't > afford to break things. To me, the MTA is like the transmission of the bus, > which is already full of kids I'm about to drive to summer camp. And I don't > know about you, I have no intention of swapping out transmissions until I > know I won't end up on the side of the road praying for a tow truck.... Actually, yes, I will laugh at those people because the switch to postfix has been painless and even if it wasn't, it is easier to solve any problems that creep up than it ever was with sendmail. -jon From dgc@uchicago.edu Tue Aug 14 02:15:31 2001 From: dgc@uchicago.edu (David Champion) Date: Mon, 13 Aug 2001 20:15:31 -0500 Subject: [Mailman-Developers] Re: mm-handler In-Reply-To: <20010726004710.B9012@smack.uchicago.edu> References: <5.1.0.14.2.20010726013750.05f5d040@lennier.cc.vt.edu> <20010726004710.B9012@smack.uchicago.edu> Message-ID: <20010813201531.C16110@smack.uchicago.edu> --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On 2001.07.26, in <20010726004710.B9012@smack.uchicago.edu>, "David Champion" wrote: > > Yes, the instructions are a bit out of date. > > You can find an only-marginally-outdated version of mm-handler in the > mailman-developers archive; the full directions on how to make it go are > what's mainly missing here. > > I'll try to put those together RSN. Finally, here's a draft that I think should be fairly complete. This copy of mm-handler is slightly different; it's a little less snooty and more easily configured, and its date treatment (for generating envelope From_ lines) is 2822-compliant instead of taking a fair shot in the Unix tradition. Also attached: mm-handler.readme, a sample virtusertable for RFC 2142 address exceptions, and a toy sendmail.mc file that really works. Changes are mostly welcome, but I'd like to know just so that I can keep my own CVS in sync with Mailman's for now. Barry, you should check step 0xA in mm-handler.readme. You need to make some changes there, I think. :) I'd appreciate someone's stepping through this like a newbie and noting problems. -- -D. dgc@uchicago.edu NSIT University of Chicago --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mm-handler.readme" What? ----- Mm-handler is a mail delivery agent (MDA) -- a "mailer", in Sendmail lingo. Its function is to assume authority for messages destined to Mailman lists, so that they're off sendmail's hands, and you (the site administrator) don't need to maintain databases of aliases and such. It takes a small bit of work to set up, but once that's done, you'll never need to mess with aliases for Mailman's sake again. When? ----- The only further catch is that mm-handler is only really useful when it mostly "owns" its mail domain (the hostname part after an e-mail address's "@" symbol) -- when you can dedicate the mail domain to Mailman. If you have a limited set of exceptions -- a few users, for example -- you can still use it, but for sites with a dynamic or even mix of users (or forwarders) and lists, it might not gain you much. How do you know whether mm-handler is appropriate for you? Let's look at some examples. If you're running lists off your primary DNS domain name, you probably have a mix of lists and users in your namespace. Take python.org, for example: it hosts Mailman lists, and it hosts users' personal accounts. There aren't a whole bunch of either, but the ratio is probably fairly near 1:1. Mm-handler is not very useful here, because there's no simple way to separate user addresses from list addresses -- not to mention that mm-handler is written in perl, so that's just bad form. This begs two different, complementary situations. A hypothetical domain, incidents.int, is used mostly for mailing lists. It's a front-end site, and not a general user mail service. There might be a couple of user addresses -- system administrators and such -- but these are few in number and easily adjusted manually by the site administrator. The 250 mailing lists at the site are much more dynamic, and a much bigger pain to keep track of by editing an alias file. This site can easily benefit from mm-handler. Inversely, mail.aero, another hypothetical domain, provides POP mail service to employees of the aerospace industry. Its addresses are almost entirely users, although it maintains a few mailing lists for convenience. This site has nothing to gain from mm-handler. It's much easier to maintain an alias file of 10 lists than to dedicate the domain to Mailman, and put all 10,000 aerospace workers in a user table. Those a are the trickier cases. The case where mm-handler really works best is when you can dedicate a single hostname under your DNS domain to mailing lists, and host no user accounts there. At the University of Chicago, we do this with listhost.uchicago.edu. SourceForge does this, too, although I don't believe they use Sendmail. If your site is like that, you should read on. How? ---- Set-up isn't all that complicated. I've included a file here called "mailman.mc". This is the m4 file that I use on my list server, and you can likely use it with few changes at your site. It's well-annotated; the rationale for each parameter (or set of parameters) is provided in m4 (ahem) comments. So, the simple steps are as follows: 1. Copy mailman.mc, and make any changes you need at your site. You DEFINITELY need some changes. There are hostnames in there that you need to adjust, and chances are that you'll need to change some other parameters (like the host OS), too. [1] 2. Install mm-handler. Because my server's sendmail-related files live in /etc/mail, I keep mm-handler there, too. YMMV. 3. Edit mm-handler, and make any changes you need at your site. You probably want to change $MMWRAPPER and $MMLISTDIR at line 14, and you *might* want to take a look at the helpful boilerplate text beginning at line 64. (This text is sent whenever someone tries to send mail to a nonexistent list address on your mail domain.) 4. You should set up a virtusertable. (See mailman.mc for an explanation.) There's an example of a good, minimal virtusertable in this distribution. The virtusertable begins as a text file named "virtusertable", stored in the same directory as all the other Sendmail files, but it's converted to a map file for Sendmail's use. Install the virtusertable, and (re)make the map file. [2] 5. You absolutely must have a mailertable, or all of this goes nowhere. Like virtusertable, the mailertable is a map that begins as text and gets converted. It's named "mailertable", and it's probably pretty simple. Mine looks like this: listtest.uchicago.edu mailman:listtest.uchicago.edu This says: assign all incoming mail (that was not intercepted by the virtusertable) and that is in the listtest.uchicago.edu domain to the "mailman" mailer, and tell the "mailman" mailer that the hostname we're using is "listtest.uchicago.edu". You can support multiple virtual hosts using mm-handler just by placing corresponding lines in mailertable. Be sure to make this map, too! 6. The mailer definition (see the end of mailman.mc, or your own .mc file) for mm-handler sets the user/group that mm-handler will run under. (I use mailman:other.) Be sure that mm-handler is executable by this user or group. You almost certainly need the user to be the same as the Mailman user, and this user is almost always called "mailman", so you probably shouldn't change the defaults. 7. Generate your new sendmail.cf file. See the sendmail documentation if you're not familiar with this procedure. [1] 8. Stop sendmail on your list server, if you haven't already. Install the new sendmail.cf file wherever your sendmail.cf file belongs. (This depends on how sendmail was compiled, but most systems support using /etc/sendmail.cf.) 9. Cross your fingers and restart sendmail. A. Barry warns that Mailman now needs you to modify your Mailman/mm_cfg.py file, adding this line: MTA = None But this isn't in my latest installation, and I don't remember what it's for, so I'll leave this to Barry to clarify. :) That's it! With any luck, you're fully functional. -- [1] The .mc file is the standard, supported way of configuring sendmail. I'm not going to get into this here, and I'm not going to tell you how to write raw sendmail.cf stuff, because if you need to do it this way then you need something more comprehensive than I can provide. If you need help with the .mc -> .cf process, I recommend these links: http://www.sendmail.org/~ca/email/setup1.html http://www.sendmail.org/~ca/email/doc8.9/README.cf.html http://www.hserus.net/sendmail.html [2] This is often done with something like "makemap hash /etc/virtusertable /tmp/mm-$$"; $sendmail = new FileHandle "|$SENDMAIL $to"; if (!defined($sendmail)) { print STDERR "$0: cannot exec \"$SENDMAIL\"\n"; exit (-1); } $sendmail->print ("From: MAILER-DAEMON\@$server To: $to Subject: Returned mail: List unknown Mime-Version: 1.0 Content-type: multipart/mixed; boundary=\"$BOUNDARY\" Content-Disposition: inline --$BOUNDARY Content-Type: text/plain; charset=us-ascii Content-Description: Error processing your mail Content-Disposition: inline Your mail for $list could not be sent: $reason For a list of publicly-advertised mailing lists hosted on this server, visit this URL: http://$server/ If this does not resolve your problem, you may write to: postmaster\@$server or mailman-owner\@$server $servname delivers e-mail to registered mailing lists and to the administrative addresses defined and required by IETF Request for Comments (RFC) 2142 [1]. $NOUSERS The Internet Engineering Task Force [2] (IETF) oversees the development of open standards for the Internet community, including the protocols and formats employed by Internet mail systems. For your convenience, your original mail is attached. [1] Crocker, D. \"Mailbox Names for Common Services, Roles and Functions\". http://www.ietf.org/rfc/rfc2142.txt [2] http://www.ietf.org/ --$BOUNDARY Content-Type: message/rfc822 Content-Description: Your undelivered mail Content-Disposition: attachment "); while ($_ = <$in>) { $sendmail->print ($_); } $sendmail->print ("\n"); $sendmail->print ("--$BOUNDARY--\n"); close($sendmail); } ## Get my IP address, in case my sendmail doesn't tell me my name. sub get_ip_addr { my $host = hostname; my $ip = gethostbyname($host); return inet_ntoa($ip); } ## Split an address into its base list name and the appropriate command ## for the relevant function. sub split_addr { my ($addr) = @_; my ($list, $cmd); if ($addr =~ /(.*)-admin$/ || $addr =~ /(.*)-owner$/ || $addr =~ /^owner-(.*)$/) { $list = $1; $cmd = "mailowner"; } elsif ($addr =~ /(.*)-request$/) { $list = $1; $cmd = "mailcmd"; } else { $list = $addr; $cmd = "post"; } return ($list, $cmd); } ## The time, formatted as for an mbox's "From_" line. sub mboxdate { my ($time) = @_; my @days = qw(Sun Mon Tue Wed Thu Fri Sat); my @months = qw(Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec); my ($sec, $min, $hour, $mday, $mon, $year, $wday, $yday, $isdst) = localtime($time); ## Two-digit year handling complies with RFC 2822 (section 4.3), ## with the addition that three-digit years are accommodated. if ($year < 50) { $year += 2000; } elsif ($year < 1900) { $year += 1900; } return sprintf ("%s %s %2d %02d:%02d:%02d %d", $days[$wday], $months[$mon], $mday, $hour, $min, $sec, $year); } BEGIN: { $sender = undef; $server = undef; @to = (); while ($#ARGV >= 0) { if ($ARGV[0] eq "-r") { $sender = $ARGV[1]; shift @ARGV; } elsif (!defined($server)) { $server = $ARGV[0]; } else { push(@to, $ARGV[0]); } shift @ARGV; } if ($DEBUG) { $to = join(',', @to); print STDERR "to: $to\n"; print STDERR "sender: $sender\n"; print STDERR "server: $server\n"; exit(-1); } ADDR: for $addr (@to) { $prev = undef; $list = $addr; $cmd= "post"; if (! -f "$MMLISTDIR/$list/config.db") { ($list, $cmd) = &split_addr($list); if (! -f "$MMLISTDIR/$list/config.db") { $was_to = $addr; $was_to .= "\@$server" if ("$server" ne ""); mail_error(\*STDIN, $sender, $was_to, $server, "no list named \"$list\" is known by $server"); next ADDR; } } $wrapper = new FileHandle "|$MMWRAPPER $cmd $list"; if (!defined($wrapper)) { ## Defer? print STDERR "$0: cannot exec ", "\"$MMWRAPPER $cmd $list\": deferring\n"; exit (-1); } # Don't need these without the "n" flag on the mailer def.... #$date = &mboxdate(time); #$wrapper->print ("From $sender $date\n"); # ...because we use these instead. $from_ = ; $wrapper->print ($from_); $wrapper->print ("X-Mailman-Handler: $VERSION\n"); while () { $wrapper->print ($_); } close($wrapper); } } --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mailman.mc" dnl dnl *** EXAMPLE *** sendmail.mc file for a Mailman list server using dnl mm-handler to deal with list operations (in place of aliases). dnl This is what I actually use on my site. dnl dnl $Id: mailman.mc,v 1.2 2001/08/14 00:50:34 dgc Exp $ dnl dnl dnl First you need to define your general characteristics. You dnl should know what these settings should be at your site -- I dnl only know what they should be at mine. dnl OSTYPE(solaris2)dnl DOMAIN(generic)dnl dnl dnl You can keep the old alias files for back-compatibility, but it's dnl probably better not to as this can become a point of confusion dnl later. dnl define(`ALIAS_FILE', `/etc/mail/aliases,/etc/mail/lists') dnl dnl I use procmail for local delivery, because it's smart to have a dnl local delivery mailer, even if you don't (ordinarily) do any local dnl delivery. The Solaris local delivery mailer is part of its sendmail dnl package. I pkgrmed the sendmail packages so that system upgrades dnl don't kill my sendmail.com sendmail, so mail.local is unavailable, dnl so I throw procmail in here even though it never gets used. dnl define(`PROCMAIL_MAILER_PATH', `/opt/bin/procmail') FEATURE(`local_procmail') MAILER(`local') dnl dnl Miscellaneous tuning. Not relevant to Mailman. dnl define(`confCONNECTION_RATE_THROTTLE', 5) define(`confMAX_MESSAGE_SIZE', `5000000') define(`confNO_RCPT_ACTION', `add-to-undisclosed') define(`confME_TOO', `True') define(`confDOUBLE_BOUNCE_ADDRESS', `mailer-daemon') dnl dnl Privacy options. Also not relevant. dnl define(`confPRIVACY_FLAGS', `authwarnings,needvrfyhelo,noexpn,noreceipts,restrictmailq') dnl dnl Mm-handler works by mailertabling all addresses on your list dnl server hostname(s) through the mm-handler mailer. Mailertable dnl maps mail domains to mailer types. I want a mailertable to map dnl listtest.uchicago.edu to the mm-handler mailer, but we need to dnl specifically request this functionality in the .mc file. dnl FEATURE(`mailertable', `hash -o /etc/mail/mailertable') dnl dnl This leads to an immediate and important side-effect: "local" dnl addresses, and notably RFC-specified addresses such as postmaster, dnl are assumed by sendmail to be lists! Since aliases are not processed dnl for domaintabled domains, we must use a virtusertable to reroute dnl such addresses. dnl FEATURE(`virtusertable', `hash -o /etc/mail/virtusertable') dnl dnl By default, sendmail applies virtusertable mapping, if at all, for dnl all interfaces for which it accepts mail -- i.e., all domains in dnl $=w. Mm-handler relies on your having a single domain (hostname) dnl that serves only lists, with no users. To avoid potential namespace dnl conflicts, you need not to have this list domain included in $=w. dnl As a result, virtuser mapping does not apply for the Mailman dnl list domain. However, you can pre-empt this rule by defining dnl $={VirtHost}: if there are domains in this class, they will be dnl mapped before $=w is mapped. dnl dnl VIRTUSER_DOMAIN() defines this class. dnl VIRTUSER_DOMAIN(`nospam.uchicago.edu listtest.uchicago.edu listhost.uchicago.edu') dnl dnl On a related point: by default, Sendmail probes for open IP dnl interfaces, and adds their hostnames to $=w. Although Sendmail does dnl virtusertable mapping for members of $=w, it doesn't do mailertable dnl mapping for them, because they're considered "local". This tells dnl Sendmail not to probe interfaces for local hosts, and it's critical dnl if your Mailman domain is actually an IP address (with an A record, dnl not just CNAME or MX) on your server. dnl define(`confDONT_PROBE_INTERFACES', `True') dnl dnl Even though my actual hostname is foobar, tell the world that I'm dnl listtest.uchicago.edu. dnl FEATURE(`limited_masquerade') MASQUERADE_AS(`listtest.uchicago.edu') dnl dnl Access control is a useful feature for blocking abusers and relays dnl and such. dnl FEATURE(`access_db') dnl dnl This allows you to block access for individual recipents through dnl the same access database as is used for blocking sender hosts and dnl addresses. dnl FEATURE(`blacklist_recipients') dnl dnl Other local mailers... dnl MAILER(`smtp') MAILER(`procmail') dnl dnl Our Mailman-specific local mailer. dnl MAILER_DEFINITIONS #################################### ### New Mailer specifications ### #################################### ## Special flags! See ## http://www.sendmail.org/~ca/email/doc8.10/op-sh-5.html#sh-5.4 ## Note especially the absence of the "m" and "n" flags. THIS IS ## IMPORTANT: mm-handler assumes this behavior to avoid having to know ## too much about address parsing and other RFC-2822 mail details. Mmailman, P=/etc/mail/mm-handler, F=rDFMhlqSu, U=mailman:other, S=EnvFromL, R=EnvToL/HdrToL, A=mm-handler $h $u --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=virtusertable ## ## Example virtusertable for use with a Mailman site running mm-handler. ## ## $Id: virtusertable,v 1.1 2001/08/14 00:43:08 dgc Exp $ ## ## ## My server's hostname is nospam, but we don't honor that as a ## Mailman mail domain. Anything @nospam.uchicago.edu should be ## forwarded to our master Mailman admin address. ## @nospam.uchicago.edu mailman-owner@midway.uchicago.edu ## ## Redirect mail to the standard Mailman admin addresses to the ## master admin address. (Midway.uchicago.edu is our site's central ## mail-routing server, and it carries aliases for maintenance groups. ## Not a good plan to entrust Mailman maintenance mail to Mailman.) ## mailman@listhost.uchicago.edu mailman-owner@midway.uchicago.edu mailman-owner@listhost.uchicago.edu mailman-owner@midway.uchicago.edu ## ## These addresses are required or recommended either by convention ## or by RFC 2142, "Mailbox Names for Common Services, Roles and ## Functions". Honor them. ## MAILER-DAEMON@listhost.uchicago.edu mailman-owner@midway.uchicago.edu postmaster@listhost.uchicago.edu mailman-owner@midway.uchicago.edu webmaster@listhost.uchicago.edu mailman-owner@midway.uchicago.edu abuse@listhost.uchicago.edu sun-admin@midway.uchicago.edu root@listhost.uchicago.edu sun-admin@midway.uchicago.edu ## ## If I had a need, I could put user accounts in here, too. ## dgc@listhost.uchicago.edu dgc@where.my.mail.really.goes --9jxsPFA5p3P2qPhR-- From dgc@uchicago.edu Tue Aug 14 02:22:36 2001 From: dgc@uchicago.edu (David Champion) Date: Mon, 13 Aug 2001 20:22:36 -0500 Subject: [Mailman-Developers] Re: mm-handler In-Reply-To: <20010813201531.C16110@smack.uchicago.edu> References: <5.1.0.14.2.20010726013750.05f5d040@lennier.cc.vt.edu> <20010726004710.B9012@smack.uchicago.edu> <20010813201531.C16110@smack.uchicago.edu> Message-ID: <20010813202236.D16110@smack.uchicago.edu> On 2001.08.13, in <20010813201531.C16110@smack.uchicago.edu>, "David Champion" wrote: > > Finally, here's a draft that I think should be fairly complete. This > copy of mm-handler is slightly different; it's a little less snooty and > more easily configured, and its date treatment (for generating envelope > From_ lines) is 2822-compliant instead of taking a fair shot in the Unix > tradition. Not that it matters. This is vestigial of a time when I hadn't yet started using all the neat mailer flags that you can declare on a mailer definition, and it's not actually relevant anymore. My brain just stalled for a bit as I was writing that intro, and I improvised. -- -D. dgc@uchicago.edu NSIT University of Chicago From mentor@alb-net.com Tue Aug 14 02:26:37 2001 From: mentor@alb-net.com (Mentor Cana) Date: Mon, 13 Aug 2001 21:26:37 -0400 (EDT) Subject: [Mailman-Developers] sendmail In-Reply-To: Message-ID: On Mon, 13 Aug 2001, at 17:05 -0700, Jon Stevens wrote: > Actually, yes, I will laugh at those people because the switch to postfix > has been painless and even if it wasn't, it is easier to solve any problems > that creep up than it ever was with sendmail. > > -jon So far I've kept both postfix and sendmail running. initially I was running postfix on port other than 25 and sendmail on 25. Now I've switched to a point where postfix handle my inbound and outbound mail (port 25) and running sendmail on port 587. The switch was painless, besides that I had to familiarize myself with postfix. The aliases, virtual maps, etc, are all compatible. Why do I keep sendmail around? Well, the new version is about the come out (8.12) and there are promises for better performance and more functionality. I would like to test this latest release of sendmail before I say good bay...... So far my vote is for postfix: easy to setup, easy to maintain, easy to upgrade, etc..... -- Mentor From rodolfo@linux.org.uy Tue Aug 14 03:37:51 2001 From: rodolfo@linux.org.uy (Rodolfo Pilas) Date: Mon, 13 Aug 2001 23:37:51 -0300 Subject: [Mailman-Developers] Cool error! Message-ID: <20010813233751.479d721c.rodolfo@linux.org.uy> This is a multi-part message in MIME format. --Multipart_Mon__13_Aug_2001_23:37:51_-0300_0830abd0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I have a list with private_roster set to "admin only" (I do not know the internal sintax). But the listinfo shows many errors, you can see at http://www.espaciolibre.net/cgi-bin/listinfo/uylug-noticias and in the attached html file. The problem is just in the text "This is a XX...XXX shadow list" for this reason I underestand that this is a problema of the Spanish translation. -- ____________________________________________________ -=(( Rodolfo Pilas - rodolfo@linux.org.uy ))=- -==((( Are you ready for XtraLinuX - http://xtralinux.org )))==- -=((____________________________________________________))=- Guarde sus mail en Echelon: OLP, Greenpeace, ETA, Hamas, Hizbullah, FMI Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 --Multipart_Mon__13_Aug_2001_23:37:51_-0300_0830abd0 Content-Type: application/octet-stream; name="uylug-noticias.1" Content-Disposition: attachment; filename="uylug-noticias.1" Content-Transfer-Encoding: base64 PCEtLSAkUmV2aXNpb246IDIuMCAkIC0tPg0KPEhUTUw+DQogIDxIRUFEPg0KICAgIDxUSVRMRT5Q JmFhY3V0ZTtnaW5hIGRlIEluZm9ybWFjaSZvYWN1dGU7biBkZSB1eWx1Zy1ub3RpY2lhczwvVElU TEU+DQogIA0KICA8L0hFQUQ+DQogIDxCT0RZIEJHQ09MT1I9IiNmZmZmZmYiPg0KICAgIDxQPg0K ICAgICAgPFRBQkxFIENPTFM9IjEiIEJPUkRFUj0iMCIgQ0VMTFNQQUNJTkc9IjQiIENFTExQQURE SU5HPSI1Ij4NCgk8VFI+DQoJICA8VEQgQ09MU1BBTj0iMiIgV0lEVEg9IjEwMCUiIEJHQ09MT1I9 IiM5OUNDRkYiIEFMSUdOPSJDRU5URVIiPg0KCSAgICA8Qj48Rk9OVCBDT0xPUj0iIzAwMDAwMCIg U0laRT0iKzEiPnV5bHVnLW5vdGljaWFzIC0tDQoJTm90aWNpYXMgZGVsIFVZTFVHIChzb2xvIGxl Y3R1cmEpPC9GT05UPjwvQj4NCgkgIDwvVEQ+DQoJPC9UUj4NCgk8dHI+DQoJICAgIDx0ZCBjb2xz cGFuPSIyIj4NCgkgICAgICA8cD4mbmJzcDsNCgkgICAgPC90ZD4NCgkgIDwvdHI+DQoJICA8dHI+ DQoJICAgIDxURCBDT0xTUEFOPSIxIiBXSURUSD0iMTAwJSIgQkdDT0xPUj0iI0ZGRjBEMCI+DQoJ ICAgICAgPEI+PEZPTlQgQ09MT1I9IiMwMDAwMDAiPlNvYnJlICB1eWx1Zy1ub3RpY2lhczwvRk9O VD48L0I+DQoJICAgIDwvVEQ+DQoJICAgIDxURCBDT0xTUEFOPSIxIiBXSURUSD0iMTAwJSIgQkdD T0xPUj0iI0ZGRjBEMCI+DQoJICAgICAgPEZPUk0gTWV0aG9kPVBPU1QgQUNUSU9OPSIuLi9saXN0 aW5mby91eWx1Zy1ub3RpY2lhcyI+PElOUFVUIHR5cGU9IlN1Ym1pdCIgbmFtZT0iZGlzcGxhbmct YnV0dG9uIiB2YWx1ZT0iVmVyIGVzdGEgcCZhYWN1dGU7Z2luYSBlbiAiPiAKPFNlbGVjdCBuYW1l PSJsYW5ndWFnZSI+CiA8b3B0aW9uIHZhbHVlPSJlcyIgU2VsZWN0ZWQ+IEVzcGEmbnRpbGRlO29s IChFc3BhJm50aWxkZTthKSA8L29wdGlvbj4KPC9TZWxlY3Q+DQoJICAgICAgPC9GT1JNPg0KCSAg ICA8L1REPg0KCSAgPC9UUj4NCgkgICAgPHRyPg0KCSAgICAgIDx0ZCBjb2xzcGFuPSIyIj4NCgkJ PFA+PGEgaHJlZj0iaHR0cDovL3d3dy5saW51eC5vcmcudXkiPjxpbWcgc3JjPSJodHRwOi8vd3d3 LnV5bHVnLm9yZy51eS9sb2dvLXV5bHVnLnBuZyIgYm9yZGVyPSIwIj48YnI+U2l0aW8gZGVsIFVZ TFVHPC9hPjwvUD4NCgkgIDxwPiAgUGFyYSB2ZXIgZW52JmlhY3V0ZTtvcyBhbnRlcmlvcmVzIGEg bGEgbGlzdGEsDQoJICAgICAgIHB1ZWRlIHZpc2l0YXIgbG9zIGFyY2hpdm9zIGRlIDxhIGhyZWY9 Ii9waXBlcm1haWwvdXlsdWctbm90aWNpYXMvIj51eWx1Zy1ub3RpY2lhcw0KCQkgIDwvYT4uDQoJ ICAgICAgDQoJICA8L3A+DQoJPC9URD4NCiAgICAgIDwvVFI+DQogICAgICA8VFI+DQoJPFREIENP TFNQQU49IjIiIFdJRFRIPSIxMDAlIiBCR0NPTE9SPSIjRkZGMEQwIj4NCgkgIDxCPjxGT05UIENP TE9SPSIjMDAwMDAwIj5Db21vIHVzYXIgbGEgbGlzdGEgIHV5bHVnLW5vdGljaWFzPC9GT05UPjwv Qj4NCgk8L1REPg0KICAgICAgPC9UUj4NCiAgICAgIDx0cj4NCgk8dGQgY29sc3Bhbj0iMiI+DQoJ ICBQYXJhIGVudmlhciB1biBtZW5zYWplIGEgdG9kb3MgbG9zIG1pZW1icm9zIGRlIGxhIGxpc3Rh LA0KCSAgZW52JmlhY3V0ZTtlbG8gYSBsYSBkaXJlY2NpJm9hY3V0ZTtuDQoJICA8QSBIUkVGPSJt YWlsdG86dXlsdWctbm90aWNpYXNAdXlsdWcub3JnLnV5Ij51eWx1Zy1ub3RpY2lhc0B1eWx1Zy5v cmcudXk8L0E+Lg0KDQoJICA8cD5QdWVkZSB1c3RlZCBzdWJzY3JpYmlyc2UgYSBsYSBsaXN0YSwg byBjYW1iaWFyIHN1DQoJICAgIHN1YnNjcmlwY2kmb2FjdXRlO24sIGVuIGxhcyBzaWd1aWVudGVz IHNlY2Npb25lcy4NCgk8L3RkPg0KICAgICAgPC90cj4NCiAgICAgIDxUUj4NCgk8VEQgQ09MU1BB Tj0iMiIgV0lEVEg9IjEwMCUiIEJHQ09MT1I9IiNGRkYwRDAiPg0KCSAgPEI+PEZPTlQgQ09MT1I9 IiMwMDAwMDAiPlN1YnNjcmliaXJzZSBhIHV5bHVnLW5vdGljaWFzPC9GT05UPjwvQj4NCgk8L1RE Pg0KICAgICAgPC9UUj4NCiAgICAgIDx0cj4NCgk8dGQgY29sc3Bhbj0iMiI+DQoJICA8UD4NCgkg ICAgU3Vic2NyaWJhc2UgYSB1eWx1Zy1ub3RpY2lhcyByZWxsZW5hbmRvIGxvcyBkYXRvcyBkZWwN CgkgICAgc2lndWllbnRlIGZvcm11bGFyaW8uDQoJICA8Rk9STSBNZXRob2Q9UE9TVCBBQ1RJT049 Ii4uL3N1YnNjcmliZS91eWx1Zy1ub3RpY2lhcyI+DQoJICA8cD5TZSBsZSBtYW5kYXImYWFjdXRl OyB1biBtZW5zYWplIGRlIGNvcnJlbyBlbGVjdHImb2FjdXRlO25pY28gcGlkaWVuZG9sZSB1bmEg Y29uZmlybWFjaSZvYWN1dGU7biwgZXN0byBwcmV2aWVuZSBxdWUgb3RyYXMgcGVyc29uYXMgbGUg c3Vic2NyaWJhbiBzaW4gcXVlIHVzdGVkIGxvIHNlcGEuICAgRXN0YSBlcyB7J1VuZGVybGluZSc6 IDxjbGFzcyBNYWlsbWFuLmh0bWxmb3JtYXQuVW5kZXJsaW5lIGF0IDB4ODIyZTM1Yz4sICdJbnB1 dE9iaic6IDxjbGFzcyBNYWlsbWFuLmh0bWxmb3JtYXQuSW5wdXRPYmogYXQgMHg4MjJlOGFjPiwg J0hlYWRsZXNzRG9jdW1lbnQnOiA8Y2xhc3MgTWFpbG1hbi5odG1sZm9ybWF0LkhlYWRsZXNzRG9j dW1lbnQgYXQgMHg4MjJkZTVjPiwgJ1RhYmxlJzogPGNsYXNzIE1haWxtYW4uaHRtbGZvcm1hdC5U YWJsZSBhdCAweDgyMjVjMmM+LCAnU3VibWl0QnV0dG9uJzogPGNsYXNzIE1haWxtYW4uaHRtbGZv cm1hdC5TdWJtaXRCdXR0b24gYXQgMHg4MjJlYTBjPiwgJ0Zvcm0nOiA8Y2xhc3MgTWFpbG1hbi5o dG1sZm9ybWF0LkZvcm0gYXQgMHg4MjJlODFjPiwgJ0hlYWRlcic6IDxjbGFzcyBNYWlsbWFuLmh0 bWxmb3JtYXQuSGVhZGVyIGF0IDB4ODIyY2NlYz4sICdFTVBUWVNUUklORyc6ICcnLCAnRGljdE1l cmdlJzogPGZ1bmN0aW9uIERpY3RNZXJnZSBhdCAweDgyMjljYjQ+LCAnVXRpbHMnOiA8bW9kdWxl ICdNYWlsbWFuLlV0aWxzJyBmcm9tICcuLi9NYWlsbWFuL1V0aWxzLnB5Yyc+LCAnVmVydGljYWxT cGFjZXInOiA8Y2xhc3MgTWFpbG1hbi5odG1sZm9ybWF0LlZlcnRpY2FsU3BhY2VyIGF0IDB4ODIy ZGZiYz4sICdDYXNlSW5zZW5zaXRpdmVLZXllZERpY3QnOiA8ZnVuY3Rpb24gQ2FzZUluc2Vuc2l0 aXZlS2V5ZWREaWN0IGF0IDB4ODIyYWJhYz4sICdIVE1MRm9ybWF0T2JqZWN0JzogPGZ1bmN0aW9u IEhUTUxGb3JtYXRPYmplY3QgYXQgMHg4MjJkMjBjPiwgJ1BZVEhPTl9VUkwnOiAnaHR0cDovL3d3 dy5weXRob24ub3JnLycsICdQYXNzd29yZEJveCc6IDxjbGFzcyBNYWlsbWFuLmh0bWxmb3JtYXQu UGFzc3dvcmRCb3ggYXQgMHg4MjJlYjc0PiwgJ1JhZGlvQnV0dG9uQXJyYXknOiA8Y2xhc3MgTWFp bG1hbi5odG1sZm9ybWF0LlJhZGlvQnV0dG9uQXJyYXkgYXQgMHg4MjJlMDZjPiwgJ1N1cGVyc2Ny aXB0JzogPGNsYXNzIE1haWxtYW4uaHRtbGZvcm1hdC5TdXBlcnNjcmlwdCBhdCAweDgyMmU2NTQ+ LCAndHlwZXMnOiA8bW9kdWxlICd0eXBlcycgZnJvbSAnL3Vzci9saWIvcHl0aG9uMi4wL3R5cGVz LnB5Yyc+LCAnT3JkZXJlZExpc3QnOiA8Y2xhc3MgTWFpbG1hbi5odG1sZm9ybWF0Lk9yZGVyZWRM aXN0IGF0IDB4ODIyZjk1ND4sICdUZXh0Qm94JzogPGNsYXNzIE1haWxtYW4uaHRtbGZvcm1hdC5U ZXh0Qm94IGF0IDB4ODIyZWMzYz4sICdfX25hbWVfXyc6ICdNYWlsbWFuLkhUTUxGb3JtYXR0ZXIn LCAnRm9udFNpemUnOiA8Y2xhc3MgTWFpbG1hbi5odG1sZm9ybWF0LkZvbnRTaXplIGF0IDB4ODEx ZGQzYz4sICdtbV9jZmcnOiA8bW9kdWxlICdNYWlsbWFuLm1tX2NmZycgZnJvbSAnLi4vTWFpbG1h bi9tbV9jZmcucHljJz4sICdSYWRpb0J1dHRvbic6IDxjbGFzcyBNYWlsbWFuLmh0bWxmb3JtYXQu UmFkaW9CdXR0b24gYXQgMHg4MjJmMDNjPiwgJ1N1YnNjcmlwdCc6IDxjbGFzcyBNYWlsbWFuLmh0 bWxmb3JtYXQuU3Vic2NyaXB0IGF0IDB4ODIyZTViYz4sICdfX2ZpbGVfXyc6ICcuLi9NYWlsbWFu L0hUTUxGb3JtYXR0ZXIucHljJywgJ2Fsc28nOiAnJywgJ19fYnVpbHRpbnNfXyc6IHsnT3ZlcmZs b3dFcnJvcic6IDxjbGFzcyBleGNlcHRpb25zLk92ZXJmbG93RXJyb3IgYXQgMHg4MGU0NDk0Piwg J0F0dHJpYnV0ZUVycm9yJzogPGNsYXNzIGV4Y2VwdGlvbnMuQXR0cmlidXRlRXJyb3IgYXQgMHg4 MGUzNDM0PiwgJ05vdEltcGxlbWVudGVkRXJyb3InOiA8Y2xhc3MgZXhjZXB0aW9ucy5Ob3RJbXBs ZW1lbnRlZEVycm9yIGF0IDB4ODBlMmZjYz4sICdyYW5nZSc6IDxidWlsdC1pbiBmdW5jdGlvbiBy YW5nZT4sICdmaWx0ZXInOiA8YnVpbHQtaW4gZnVuY3Rpb24gZmlsdGVyPiwgJ1VuYm91bmRMb2Nh bEVycm9yJzogPGNsYXNzIGV4Y2VwdGlvbnMuVW5ib3VuZExvY2FsRXJyb3IgYXQgMHg4MGUzMmM0 PiwgJ0tleWJvYXJkSW50ZXJydXB0JzogPGNsYXNzIGV4Y2VwdGlvbnMuS2V5Ym9hcmRJbnRlcnJ1 cHQgYXQgMHg4MGUyM2E0PiwgJ2hhc2gnOiA8YnVpbHQtaW4gZnVuY3Rpb24gaGFzaD4sICdUeXBl RXJyb3InOiA8Y2xhc3MgZXhjZXB0aW9ucy5UeXBlRXJyb3IgYXQgMHg4MGUyMDc0PiwgJ0Fzc2Vy dGlvbkVycm9yJzogPGNsYXNzIGV4Y2VwdGlvbnMuQXNzZXJ0aW9uRXJyb3IgYXQgMHg4MGUzYmQ0 PiwgJ2FwcGx5JzogPGJ1aWx0LWluIGZ1bmN0aW9uIGFwcGx5PiwgJ0luZGVudGF0aW9uRXJyb3In OiA8Y2xhc3MgZXhjZXB0aW9ucy5JbmRlbnRhdGlvbkVycm9yIGF0IDB4ODBlMzhmYz4sICdfX2Rl YnVnX18nOiAxLCAnb3JkJzogPGJ1aWx0LWluIGZ1bmN0aW9uIG9yZD4sICdfX25hbWVfXyc6ICdf X2J1aWx0aW5fXycsICdldmFsJzogPGJ1aWx0LWluIGZ1bmN0aW9uIGV2YWw+LCAnWmVyb0Rpdmlz aW9uRXJyb3InOiA8Y2xhc3MgZXhjZXB0aW9ucy5aZXJvRGl2aXNpb25FcnJvciBhdCAweDgwZTQ2 MzQ+LCAnY2FsbGFibGUnOiA8YnVpbHQtaW4gZnVuY3Rpb24gY2FsbGFibGU+LCAnbGVuJzogPGJ1 aWx0LWluIGZ1bmN0aW9uIGxlbj4sICdtYXgnOiA8YnVpbHQtaW4gZnVuY3Rpb24gbWF4PiwgJ2J1 ZmZlcic6IDxidWlsdC1pbiBmdW5jdGlvbiBidWZmZXI+LCAnRU9GRXJyb3InOiA8Y2xhc3MgZXhj ZXB0aW9ucy5FT0ZFcnJvciBhdCAweDgwZTJjMTQ+LCAnTm9uZSc6IE5vbmUsICdtYXAnOiA8YnVp bHQtaW4gZnVuY3Rpb24gbWFwPiwgJ1ZhbHVlRXJyb3InOiA8Y2xhc3MgZXhjZXB0aW9ucy5WYWx1 ZUVycm9yIGF0IDB4ODBlNDkzYz4sICdzbGljZSc6IDxidWlsdC1pbiBmdW5jdGlvbiBzbGljZT4s ICdhYnMnOiA8YnVpbHQtaW4gZnVuY3Rpb24gYWJzPiwgJ2dldGF0dHInOiA8YnVpbHQtaW4gZnVu Y3Rpb24gZ2V0YXR0cj4sICdjb21wbGV4JzogPGJ1aWx0LWluIGZ1bmN0aW9uIGNvbXBsZXg+LCAn ZXhlY2ZpbGUnOiA8YnVpbHQtaW4gZnVuY3Rpb24gZXhlY2ZpbGU+LCAnRmxvYXRpbmdQb2ludEVy cm9yJzogPGNsYXNzIGV4Y2VwdGlvbnMuRmxvYXRpbmdQb2ludEVycm9yIGF0IDB4ODBlNDdiND4s ICdtaW4nOiA8YnVpbHQtaW4gZnVuY3Rpb24gbWluPiwgJ09TRXJyb3InOiA8Y2xhc3MgZXhjZXB0 aW9ucy5PU0Vycm9yIGF0IDB4ODBlMmE4Yz4sICdSdW50aW1lRXJyb3InOiA8Y2xhc3MgZXhjZXB0 aW9ucy5SdW50aW1lRXJyb3IgYXQgMHg4MGUyZTNjPiwgJ2xvY2Fscyc6IDxidWlsdC1pbiBmdW5j dGlvbiBsb2NhbHM+LCAnaWQnOiA8YnVpbHQtaW4gZnVuY3Rpb24gaWQ+LCAndW5pY2hyJzogPGJ1 aWx0LWluIGZ1bmN0aW9uIHVuaWNocj4sICdFbnZpcm9ubWVudEVycm9yJzogPGNsYXNzIGV4Y2Vw dGlvbnMuRW52aXJvbm1lbnRFcnJvciBhdCAweDgwZTI3MGM+LCAnaXNzdWJjbGFzcyc6IDxidWls dC1pbiBmdW5jdGlvbiBpc3N1YmNsYXNzPiwgJ2ludGVybic6IDxidWlsdC1pbiBmdW5jdGlvbiBp bnRlcm4+LCAnY29lcmNlJzogPGJ1aWx0LWluIGZ1bmN0aW9uIGNvZXJjZT4sICdLZXlFcnJvcic6 IDxjbGFzcyBleGNlcHRpb25zLktleUVycm9yIGF0IDB4ODBlMmQ3Yz4sICdyZWR1Y2UnOiA8YnVp bHQtaW4gZnVuY3Rpb24gcmVkdWNlPiwgJ19faW1wb3J0X18nOiA8YnVpbHQtaW4gZnVuY3Rpb24g X19pbXBvcnRfXz4sICdJbXBvcnRFcnJvcic6IDxjbGFzcyBleGNlcHRpb25zLkltcG9ydEVycm9y IGF0IDB4ODBlMjU5ND4sICdvY3QnOiA8YnVpbHQtaW4gZnVuY3Rpb24gb2N0PiwgJ01lbW9yeUVy cm9yJzogPGNsYXNzIGV4Y2VwdGlvbnMuTWVtb3J5RXJyb3IgYXQgMHg4MGRlNzRjPiwgJ2NtcCc6 IDxidWlsdC1pbiBmdW5jdGlvbiBjbXA+LCAnZGlyJzogPGJ1aWx0LWluIGZ1bmN0aW9uIGRpcj4s ICdyb3VuZCc6IDxidWlsdC1pbiBmdW5jdGlvbiByb3VuZD4sICdzdHInOiA8YnVpbHQtaW4gZnVu Y3Rpb24gc3RyPiwgJ3JlbG9hZCc6IDxidWlsdC1pbiBmdW5jdGlvbiByZWxvYWQ+LCAnY29tcGls ZSc6IDxidWlsdC1pbiBmdW5jdGlvbiBjb21waWxlPiwgJ2xpc3QnOiA8YnVpbHQtaW4gZnVuY3Rp b24gbGlzdD4sICdyYXdfaW5wdXQnOiA8YnVpbHQtaW4gZnVuY3Rpb24gcmF3X2lucHV0PiwgJ3Nl dGF0dHInOiA8YnVpbHQtaW4gZnVuY3Rpb24gc2V0YXR0cj4sICdJbmRleEVycm9yJzogPGNsYXNz IGV4Y2VwdGlvbnMuSW5kZXhFcnJvciBhdCAweDgwZTNlYjQ+LCAnZGVsYXR0cic6IDxidWlsdC1p biBmdW5jdGlvbiBkZWxhdHRyPiwgJ2hhc2F0dHInOiA8YnVpbHQtaW4gZnVuY3Rpb24gaGFzYXR0 cj4sICdBcml0aG1ldGljRXJyb3InOiA8Y2xhc3MgZXhjZXB0aW9ucy5Bcml0aG1ldGljRXJyb3Ig YXQgMHg4MGU0MzE0PiwgJ3hyYW5nZSc6IDxidWlsdC1pbiBmdW5jdGlvbiB4cmFuZ2U+LCAncmVw cic6IDxidWlsdC1pbiBmdW5jdGlvbiByZXByPiwgJ1RhYkVycm9yJzogPGNsYXNzIGV4Y2VwdGlv bnMuVGFiRXJyb3IgYXQgMHg4MGUzYTc0PiwgJ3R1cGxlJzogPGJ1aWx0LWluIGZ1bmN0aW9uIHR1 cGxlPiwgJ1N0YW5kYXJkRXJyb3InOiA8Y2xhc3MgZXhjZXB0aW9ucy5TdGFuZGFyZEVycm9yIGF0 IDB4ODBlMWVjYz4sICdpc2luc3RhbmNlJzogPGJ1aWx0LWluIGZ1bmN0aW9uIGlzaW5zdGFuY2U+ LCAnRXhjZXB0aW9uJzogPGNsYXNzIGV4Y2VwdGlvbnMuRXhjZXB0aW9uIGF0IDB4ODBlMWI1Yz4s ICdTeXN0ZW1FeGl0JzogPGNsYXNzIGV4Y2VwdGlvbnMuU3lzdGVtRXhpdCBhdCAweDgwZTIxZWM+ LCAnX19kb2NfXyc6ICJCdWlsdC1pbiBmdW5jdGlvbnMsIGV4Y2VwdGlvbnMsIGFuZCBvdGhlciBv YmplY3RzLlwwMTJcMDEyTm90ZXdvcnRoeTogTm9uZSBpcyB0aGUgYG5pbCcgb2JqZWN0OyBFbGxp cHNpcyByZXByZXNlbnRzIGAuLi4nIGluIHNsaWNlcy4iLCAndHlwZSc6IDxidWlsdC1pbiBmdW5j dGlvbiB0eXBlPiwgJ2lucHV0JzogPGJ1aWx0LWluIGZ1bmN0aW9uIGlucHV0PiwgJ0lPRXJyb3In OiA8Y2xhc3MgZXhjZXB0aW9ucy5JT0Vycm9yIGF0IDB4ODBlMjkzND4sICdjaHInOiA8YnVpbHQt aW4gZnVuY3Rpb24gY2hyPiwgJ05hbWVFcnJvcic6IDxjbGFzcyBleGNlcHRpb25zLk5hbWVFcnJv ciBhdCAweDgwZTMxM2M+LCAnbG9uZyc6IDxidWlsdC1pbiBmdW5jdGlvbiBsb25nPiwgJ2hleCc6 IDxidWlsdC1pbiBmdW5jdGlvbiBoZXg+LCAnemlwJzogPGJ1aWx0LWluIGZ1bmN0aW9uIHppcD4s ICdVbmljb2RlRXJyb3InOiA8Y2xhc3MgZXhjZXB0aW9ucy5Vbmljb2RlRXJyb3IgYXQgMHg4MGRl M2VjPiwgJ1N5c3RlbUVycm9yJzogPGNsYXNzIGV4Y2VwdGlvbnMuU3lzdGVtRXJyb3IgYXQgMHg4 MGRlNWVjPiwgJ29wZW4nOiA8YnVpbHQtaW4gZnVuY3Rpb24gb3Blbj4sICdMb29rdXBFcnJvcic6 IDxjbGFzcyBleGNlcHRpb25zLkxvb2t1cEVycm9yIGF0IDB4ODBlM2Q0Yz4sICdFbGxpcHNpcyc6 IEVsbGlwc2lzLCAndW5pY29kZSc6IDxidWlsdC1pbiBmdW5jdGlvbiB1bmljb2RlPiwgJ2Rpdm1v ZCc6IDxidWlsdC1pbiBmdW5jdGlvbiBkaXZtb2Q+LCAnZ2xvYmFscyc6IDxidWlsdC1pbiBmdW5j dGlvbiBnbG9iYWxzPiwgJ2ludCc6IDxidWlsdC1pbiBmdW5jdGlvbiBpbnQ+LCAnZmxvYXQnOiA8 YnVpbHQtaW4gZnVuY3Rpb24gZmxvYXQ+LCAnU3ludGF4RXJyb3InOiA8Y2xhc3MgZXhjZXB0aW9u cy5TeW50YXhFcnJvciBhdCAweDgwZTM1OWM+LCAncG93JzogPGJ1aWx0LWluIGZ1bmN0aW9uIHBv dz4sICd2YXJzJzogPGJ1aWx0LWluIGZ1bmN0aW9uIHZhcnM+fSwgJ1NQQUNFJzogJyAnLCAnQ2Vu dGVyJzogPGNsYXNzIE1haWxtYW4uaHRtbGZvcm1hdC5DZW50ZXIgYXQgMHg4MjJlNzg0PiwgJ0Zp bGVVcGxvYWQnOiA8Y2xhc3MgTWFpbG1hbi5odG1sZm9ybWF0LkZpbGVVcGxvYWQgYXQgMHg4MjJl ZjJjPiwgJ1NlbGVjdE9wdGlvbnMnOiA8Y2xhc3MgTWFpbG1hbi5odG1sZm9ybWF0LlNlbGVjdE9w dGlvbnMgYXQgMHg4MjJmYmE0PiwgJ01haWxtYW5Mb2dvJzogPGZ1bmN0aW9uIE1haWxtYW5Mb2dv IGF0IDB4ODIyZmI3ND4sICdtc2cnOiAnU2UgbGUgbWFuZGFyJmFhY3V0ZTsgdW4gbWVuc2FqZSBk ZSBjb3JyZW8gZWxlY3RyJm9hY3V0ZTtuaWNvIHBpZGllbmRvbGUgdW5hIGNvbmZpcm1hY2kmb2Fj dXRlO24sIGVzdG8gcHJldmllbmUgcXVlIG90cmFzIHBlcnNvbmFzIGxlIHN1YnNjcmliYW4gc2lu IHF1ZSB1c3RlZCBsbyBzZXBhLiAgICcsICdBZGRyZXNzJzogPGNsYXNzIE1haWxtYW4uaHRtbGZv cm1hdC5BZGRyZXNzIGF0IDB4ODIyZTJjND4sICdfJzogPGZ1bmN0aW9uIF8gYXQgMHg4MTQ5OGZj PiwgJ0xpbmsnOiA8Y2xhc3MgTWFpbG1hbi5odG1sZm9ybWF0LkxpbmsgYXQgMHg4MjFmMTM0Piwg J3JlJzogPG1vZHVsZSAncmUnIGZyb20gJy91c3IvbGliL3B5dGhvbjIuMC9yZS5weWMnPiwgJ1By ZWZvcm1hdHRlZCc6IDxjbGFzcyBNYWlsbWFuLmh0bWxmb3JtYXQuUHJlZm9ybWF0dGVkIGF0IDB4 ODIyZTUyND4sICdzZWxmJzogPE1haWxtYW4uTWFpbExpc3QuTWFpbExpc3QgJ3V5bHVnLW5vdGlj aWFzJyBhdCA4MjNjZGVjPiwgJ0dOVV9IRUFEJzogJ2dudS1oZWFkLXRpbnkuanBnJywgJ1Vub3Jk ZXJlZExpc3QnOiA8Y2xhc3MgTWFpbG1hbi5odG1sZm9ybWF0LlVub3JkZXJlZExpc3QgYXQgMHg4 MjJlMjZjPiwgJ0JvbGQnOiA8Y2xhc3MgTWFpbG1hbi5odG1sZm9ybWF0LkJvbGQgYXQgMHg4MjJl M2Y0PiwgJ05MJzogJ1wwMTInLCAnX19kb2NfXyc6ICdSb3V0aW5lcyBmb3IgcHJlc2VudGF0aW9u IG9mIGxpc3Qtc3BlY2lmaWMgSFRNTCB0ZXh0LicsICdGb250QXR0cic6IDxjbGFzcyBNYWlsbWFu Lmh0bWxmb3JtYXQuRm9udEF0dHIgYXQgMHg4MTFkZDljPiwgJ1N0cmlrZW91dCc6IDxjbGFzcyBN YWlsbWFuLmh0bWxmb3JtYXQuU3RyaWtlb3V0IGF0IDB4ODIyZTZlYz4sICdRdW90ZWRDb250YWlu ZXInOiA8Y2xhc3MgTWFpbG1hbi5odG1sZm9ybWF0LlF1b3RlZENvbnRhaW5lciBhdCAweDgyMmNj MjQ+LCAnRG9jdW1lbnQnOiA8Y2xhc3MgTWFpbG1hbi5odG1sZm9ybWF0LkRvY3VtZW50IGF0IDB4 ODIyZGI2ND4sICdIaWRkZW4nOiA8Y2xhc3MgTWFpbG1hbi5odG1sZm9ybWF0LkhpZGRlbiBhdCAw eDgyMmVkMDQ+LCAnR05VX1VSTCc6ICdodHRwOi8vd3d3LmdudS5vcmcvJywgJ0xhYmVsJzogPGNs YXNzIE1haWxtYW4uaHRtbGZvcm1hdC5MYWJlbCBhdCAweDgyMmRhMzQ+LCAnQlInOiAnPGJyPics ICdQWVRIT05fUE9XRVJFRCc6ICdQeXRob25Qb3dlcmVkLnBuZycsICdUZXh0QXJlYSc6IDxjbGFz cyBNYWlsbWFuLmh0bWxmb3JtYXQuVGV4dEFyZWEgYXQgMHg4MjJlZGNjPiwgJ0RlZmluaXRpb25M aXN0JzogPGNsYXNzIE1haWxtYW4uaHRtbGZvcm1hdC5EZWZpbml0aW9uTGlzdCBhdCAweDgyMmZh NWM+LCAnREVMSVZFUkVEX0JZJzogJ21haWxtYW4uanBnJywgJ1N0ZENvbnRhaW5lcic6IDxjbGFz cyBNYWlsbWFuLmh0bWxmb3JtYXQuU3RkQ29udGFpbmVyIGF0IDB4ODIyZGVmND4sICdJdGFsaWMn OiA8Y2xhc3MgTWFpbG1hbi5odG1sZm9ybWF0Lkl0YWxpYyBhdCAweDgyMmU0OGM+LCAnSFRNTEZv cm1hdHRlcic6IDxjbGFzcyBNYWlsbWFuLkhUTUxGb3JtYXR0ZXIuSFRNTEZvcm1hdHRlciBhdCAw eDgyMjZmMDQ+LCAnQ29udGFpbmVyJzogPGNsYXNzIE1haWxtYW4uaHRtbGZvcm1hdC5Db250YWlu ZXIgYXQgMHg4MjJkOGQ0PiwgJ0NoZWNrQm94JzogPGNsYXNzIE1haWxtYW4uaHRtbGZvcm1hdC5D aGVja0JveCBhdCAweDgyMmYxNDQ+LCAnTUFJTE1BTl9VUkwnOiAnaHR0cDovL3d3dy5nbnUub3Jn L3NvZnR3YXJlL21haWxtYW4vaW5kZXguaHRtbCd9IHVuYSBsaXN0YSBvY3VsdGEsIGxvIHF1ZSBz aW5naW5pZmljYSBxdWUgbG9zIHN1YnNjcmlwdG9yZXMgZGUgbGEgbGlzdGEgc29sbyBlc3QmYWFj dXRlO24gZGlzcG9uaWJsZXMgcGFyYSBlbCBhZG1pbmlzdHJhZG9yIGRlIGxhIGxpc3RhLiAgIA0K CSAgPGJsb2NrcXVvdGU+DQoJICAgICAgPFRBQkxFIEJPUkRFUj0iMCIgQ0VMTFNQQUNJTkc9IjIi IENFTExQQURESU5HPSIyIg0KCQlXSURUSD0iNzAlIiBIRUlHSFQ9ICIxMTIiPg0KCQk8VFI+DQoJ CSAgPFREIEJHQ09MT1I9IiNkZGRkZGQiIFdJRFRIPSI1NSUiPkRpcmVjY2kmb2FjdXRlO24gZGUg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY29ycmVvIGVsZWN0ciZv YWN1dGU7bmljbzo8L1REPg0KCQkgIDxURCBXSURUSD0iMzMlIj48SU5QVVQgdHlwZT0iVGV4dCIg bmFtZT0iZW1haWwiIHNpemU9IjMwIj4NCgkgICAgICAgICAgPC9URD4NCgkgICAgICAgICAgPFRE IFdJRFRIPSIxMiUiPiZuYnNwOzwvVEQ+PC9UUj4NCiAgICAgICAgICAgICAgICA8VFI+DQoJICAg ICAgICAgIDxURCBDT0xTUEFOPSIzIj48Rk9OVCBTSVpFPS0xPiBEZWJlIGludHJvZHVjaXIgdW5h IGNsYXZlIGRlDQoJCXByb3RlY2NpJm9hY3V0ZTtuLiBFc3RvIGxlIGRhIHVuIGJham8gbml2ZWwg ZGUgc2VndXJpZGFkLA0KCQlwZXJvIGRlYmVyJmlhY3V0ZTthIGV2aXRhciBxdWUgb3Ryb3MgZW5y ZWRlbiBjb24gc3UNCgkJc3Vic2NyaXBjaSZvYWN1dGU7bi4gIDxiPk5vIHV0aWxpY2UgY2xhdmVz IHZhbGlvc2FzPC9iPg0KCQlMYXMgY2xhdmVzIHNlIGVudiZpYWN1dGU7YW4gdW5hIHZleiBhbCBt ZXMgY29tbyByZWNvcmRhdG9yaW8sDQoJCXBvciBjb3JyZW8gZWxlY3RyJm9hY3V0ZTtuaWNvIGEg c3VzIHByb3BpZXRhcmlvcy4NCgkgICAgICAgICAgQ2FkYSBtJmVhY3V0ZTtzLCBzZSBsZSBlbnZp YXImYWFjdXRlOyBzdSBjbGF2ZSBwb3IgY29ycmVvIGVsZWN0ciZvYWN1dGU7bmljbyBwYXJhIHJl Y29yZGFyc2VsYS4NCgkJICA8L0ZPTlQ+DQogICAgICAgICAgICAgICAgICA8L1REPg0KICAgICAg ICAgICAgICAgIDwvVFI+ICANCiAgICAgIDxUUj4NCgk8VEQgQkdDT0xPUj0iI2RkZGRkZCI+RWxp amEgdW5hIGNsYXZlOjwvVEQ+DQoJPFREPjxJTlBVVCB0eXBlPSJQYXNzd29yZCIgbmFtZT0icHci IHNpemU9IjE1Ij48L1REPg0KCTxURD4mbmJzcDs8L1REPjwvVFI+DQogICAgICA8VFI+IA0KCTxU RCBCR0NPTE9SPSIjZGRkZGRkIj5Db25maXJtZSBsYSBjbGF2ZTo8L1REPg0KCTxURD48SU5QVVQg dHlwZT0iUGFzc3dvcmQiIG5hbWU9InB3LWNvbmYiIHNpemU9IjE1Ij48L1REPg0KCTxURD4mbmJz cDsgPC9URD48L1RSPg0KICAgICAgPHRyPg0KCTxURCBCR0NPTE9SPSIjZGRkZGRkIj4maXF1ZXN0 O0VuIHF1ZSBpZGlvbWEgZGVzZWEgdmlzdWFsaXphciBzdXMgbWVuc2FqZXM/PC9URD4gDQoJPFRE PiAKPFNlbGVjdCBuYW1lPSJsYW5ndWFnZSI+CiA8b3B0aW9uIHZhbHVlPSJlcyIgU2VsZWN0ZWQ+ IEVzcGEmbnRpbGRlO29sIChFc3BhJm50aWxkZTthKSA8L29wdGlvbj4KPC9TZWxlY3Q+PC9URD4N Cgk8VEQ+Jm5ic3A7IDwvVEQ+PC9UUj4NCiAgICAgIDx0cj4NCgk8dGQ+JmlxdWVzdDtEZXNlYSBy ZWNpYmlyIGxvcyBtZW5zYWplIGRlIGNhZGEgZCZpYWN1dGU7YSByZXVuaWRvcw0KICAgICAgICAg ICAgZW4gdW4gJnVhY3V0ZTtuaWNvIG1lbnNhamUgKGRpZ2VzdCk/DQoJICA8L3RkPg0KCTx0ZD48 aW5wdXQgdHlwZT1yYWRpbyBuYW1lPSJkaWdlc3QiIHZhbHVlPSIwIiBDSEVDS0VEPiBObw0KCSAg ICA8aW5wdXQgdHlwZT1yYWRpbyBuYW1lPSJkaWdlc3QiIHZhbHVlPSIxIj4gIFMmaWFjdXRlOw0K CTwvVEQ+DQogICAgICA8L3RyPg0KICAgICAgPHRyPg0KCTx0ZCBjb2xzcGFuPSIzIj4NCgkgIDxj ZW50ZXI+PElOUFVUIHR5cGU9IlN1Ym1pdCIgbmFtZT0iZW1haWwtYnV0dG9uIiB2YWx1ZT0iU3Vi c2NyaWJpciI+PC9QPjwvY2VudGVyPg0KICAgIDwvVEFCTEU+DQogICAgPC9ibG9ja3F1b3RlPg0K ICAgIDwvRk9STT4NCiAgICA8L3VsPg0KICAgIDwvdGQ+DQogICAgPC90cj4NCiAgICA8VFI+DQog ICAgICA8VEQgQ09MU1BBTj0iMiIgV0lEVEg9IjEwMCUiIEJHQ09MT1I9IiNGRkYwRDAiPg0KCTxh IG5hbWU9InN1YnNjcmliZXJzIj4NCiAgICAgICAgPEI+PEZPTlQgQ09MT1I9IiMwMDAwMDAiPlN1 c2NyaXB0b3JlcyBkZSB1eWx1Zy1ub3RpY2lhczwvRk9OVD48L0I+PC9hPg0KICAgICAgPC9URD4N CiAgICA8L1RSPg0KICAgIDx0cj4NCiAgICAgIDxURCBDT0xTUEFOPSIyIiBXSURUSD0iMTAwJSI+ DQoJPEZPUk0gTWV0aG9kPVBPU1QgQUNUSU9OPSIuLi9yb3N0ZXIvdXlsdWctbm90aWNpYXMiPg0K CSg8aT5MYSBsaXN0YSBkZSBzdWJzY3JpcHRvcmVzIHNvbG8gZXN0JmFhY3V0ZTsgZGlzcG9uaWJs ZSBwYXJhCiAgICAgICAgICAgIGxvcyBhZG1pbml0cmFkb3JlcyBkZSBsYSBsaXN0YS48L2k+KSA8 cD5JbnRyb2R1emNhIHN1IGRpcmVjY2kmb2FjdXRlO24gZGUgY29ycmVvLWUgeSBsYSBjbGF2ZSBw YXJhIHZpc2l0YXIgbGEgbGlzdGEgZGUgc3Vic2NyaXB0b3JlczxwPjxjZW50ZXI+IERpcmVjY2km b2FjdXRlO24gZGUgY29ycmVvLWUgIDxJTlBVVCB0eXBlPSJUZXh0IiBuYW1lPSJyb3N0ZXItZW1h aWwiIHNpemU9IjIwIj4gQ2xhdmU6IDxJTlBVVCB0eXBlPSJQYXNzd29yZCIgbmFtZT0icm9zdGVy LXB3IiBzaXplPSIxNSI+Jm5ic3A7Jm5ic3A7PElOUFVUIG5hbWU9IlN1YnNjcmliZXJSb3N0ZXIi IHR5cGU9IlNVQk1JVCIgdmFsdWU9IlZpc2l0YXIgbGEgbGlzdGEgZGUgc3Vic2NyaXB0b3JlcyIg PjwvY2VudGVyPg0KCSAgICA8L0ZPUk0+DQoJICA8cD4NCgk8Rk9STSBNZXRob2Q9UE9TVCBBQ1RJ T049Ii4uL3N1YnNjcmliZS91eWx1Zy1ub3RpY2lhcyI+DQoJUGFyYSBjYW1iaWFyIGxhcyBvcGNp b25lcyBkZSBzdSBzdWJzY3JpcGNpJm9hY3V0ZTtuCiAgICAgICAgKGFjdGl2YXIgZGlnZXN0cywg Y29uc2VndWlyIHVuIHJlY29yZGF0b3JpbyBkZSBzdSBjbGF2ZSBvIGFudWxhciBzdQogICAgICAg IHN1YnNjcmlwY2kmb2FjdXRlO24gZGUgdXlsdWctbm90aWNpYXMgaW5kaXF1ZSBsYSBkaXJlY2Np Jm9hY3V0ZTtuIGRlCiAgICAgICAgY29ycmVvIGVsZWN0ciZvYWN1dGU7bmljbyBjb24gZWwgcXVl IGVzdCZhYWN1dGU7IHN1YnNjcml0bzoKICAgICAgICA8cD48Y2VudGVyPiA8SU5QVVQgbmFtZT0i aW5mbyIgdHlwZT0iVEVYVCIgdmFsdWU9IiIgc2l6ZT0iMzAiID4gIDxJTlBVVCBuYW1lPSJVc2Vy T3B0aW9ucyIgdHlwZT0iU1VCTUlUIiB2YWx1ZT0iRWRpdGFyIG9wY2lvbmVzIiA+PC9jZW50ZXI+ DQoJCTwvRk9STT4NCiAgICAgIDwvdGQ+DQogICAgPC90cj4NCiAgPC90YWJsZT4NCjxocj48YWRk cmVzcz48YSBocmVmPSIuLi9saXN0aW5mby91eWx1Zy1ub3RpY2lhcyI+dXlsdWctbm90aWNpYXM8 L2E+IGxhIGFkbWluaXN0cmEgPGEgaHJlZj0ibWFpbHRvOmVtdmVyZGVzQGludGVybmV0LmNvbS51 eSI+ZW12ZXJkZXNAaW50ZXJuZXQuY29tLnV5PC9hPjxicj48YSBocmVmPSIuLi9hZG1pbi91eWx1 Zy1ub3RpY2lhcyI+SW50ZXJmYXogYWRtaW5pc3RyYXRpdmEgZGUgdXlsdWctbm90aWNpYXM8L2E+ IChyZXF1aWVyZSBhdXRvcml6YWNpJm9hY3V0ZTtuKTxwPgo8dGFibGUgV0lEVEg9IjEwMCUiIEJP UkRFUj0iMCI+CiAgPHRyPgogICAgPHRkPjxpbWcgc3JjPSIvaW1hZ2VzL21haWxtYW4uanBnIiBh bHQ9IkRlbGl2ZXJlZCBieSBNYWlsbWFuIiBib3JkZXI9MD48YnI+dmVyc2lvbiAyLjFhMjwvdGQ+ CiAgICA8dGQ+PGltZyBzcmM9Ii9pbWFnZXMvUHl0aG9uUG93ZXJlZC5wbmciIGFsdD0iUHl0aG9u IFBvd2VyZWQiIGJvcmRlcj0wPjwvdGQ+CiAgICA8dGQ+PGltZyBzcmM9Ii9pbWFnZXMvZ251LWhl YWQtdGlueS5qcGciIGFsdD0iR05VJ3MgTm90IFVuaXgiIGJvcmRlcj0wPjwvdGQ+CiAgPC90cj4K PC90YWJsZT4KPC9hZGRyZXNzPg0KPC9CT0RZPg0KPC9IVE1MPg0KCg== --Multipart_Mon__13_Aug_2001_23:37:51_-0300_0830abd0-- From claw@kanga.nu Tue Aug 14 04:25:53 2001 From: claw@kanga.nu (J C Lawrence) Date: Mon, 13 Aug 2001 20:25:53 -0700 Subject: [Mailman-Developers] edit moderated messages? In-Reply-To: Message from "Thomas M. Parris" of "Mon, 13 Aug 2001 10:00:16 EDT." <001201c12400$487c4c30$3a28603f@CHERRYBLOSSOM> References: <001201c12400$487c4c30$3a28603f@CHERRYBLOSSOM> Message-ID: <8673.997759553@kanga.nu> On Mon, 13 Aug 2001 10:00:16 -0400 Thomas M Parris wrote: > I'm impressed by the level of attention you are all giving to > this. Here are my thoughts. > 1. admin page moderation I like the idea of a button to bring up > the entire message in an editable text box. I'd request that it be a link rather than a FORM button. That way I can middle-click on it to edit in a new browser window rather than having to use the same window that I'm moderating in. (There are coherency of thought process concerns -- I typically moderate batches of 20 - 40 messages at a time for each list, working in multiple passes across the batch, first picking out the automatic approves, then the simple rejects, etc). -- J C Lawrence )\._.,--....,'``. ---------(*) /, _.. \ _\ ;`._ ,. claw@kanga.nu `._.-(,_..'--(,_..'`-.;.' http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly From claw@kanga.nu Tue Aug 14 07:27:54 2001 From: claw@kanga.nu (J C Lawrence) Date: Mon, 13 Aug 2001 23:27:54 -0700 Subject: [Mailman-Developers] sendmail In-Reply-To: Message from Chuq Von Rospach of "Mon, 13 Aug 2001 13:47:29 PDT." References: Message-ID: <20408.997770474@kanga.nu> On Mon, 13 Aug 2001 13:47:29 -0700 Chuq Von Rospach wrote: > Me, I'm switching to postfix -- very slowly and carefully. Because > I can't afford to break things. To me, the MTA is like the > transmission of the bus, which is already full of kids I'm about > to drive to summer camp. And I don't know about you, I have no > intention of swapping out transmissions until I know I won't end > up on the side of the road praying for a tow truck.... That's the problem with real sysadm work -- the carefully side-checked and verified engineering process just isn't sexy. No flash. No sizzle. No hot babes draped over Ferraris. -- J C Lawrence )\._.,--....,'``. ---------(*) /, _.. \ _\ ;`._ ,. claw@kanga.nu `._.-(,_..'--(,_..'`-.;.' http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly From steff7@worldshare.net Tue Aug 14 08:52:46 2001 From: steff7@worldshare.net (Lorene Brownlee) Date: Tue, 14 Aug 2001 00:52:46 -0700 Subject: [Mailman-Developers] Attention Physicians Message-ID: <11997237-2200182147524610@worldshare.net> Introducing Lytec Medical 2001 The #1 Windows Based Medical Practice Manag= ement Solution=2E We are pleased to introduce Lytec Medical 2001, the #1 Windows-based medic= al software solution=2E With over 30 newly added features and greater fle= xibility, Lytec Medical 2001 streamlines and simplifies data entry, enhanc= es reporting capabilities, and improves your ability=20 to quickly access practice information=2E Lytec Medical 2001 Is A Complete Practice Management Solution And The Most= Talked About Practice Management Software In The Country=2E Our latest release of Lytec Medical 2001 contains many new and powerful fe= atures=2E Lytec Medical is now certified and licensed to carry the "Desig= ned for Microsoft Windows NT and Windows 98" logo=2E Lytec Medical 2001 f= or Windows, the most advanced upgrade of the #1 selling Window-based pract= ice management software in the United States to be released since 1992=2E = With over 22,000 Window systems sold, Lytec Medical for Windows is the mo= st popular medical billing & practice management system for Windows=2E Pr= ovides functional menu's for submitting your medical claims=20 electronically=2E Lytec Medical 2001 stands alone at=2E=2E=2E$ 671 for the Single-user version, $ 971 for the Multi-user version, and $1,346 for the Professional version=2E For the Client/Server 10-node version (Windows NT and Novell NetWare)=20 Please call for pricing=2E Order today and receive a 25% discounted rate! =20 Email us today at medicalsolution@hotmail=2Ecom We are accepting credit card order=2E Complete the buyer and shipping inf= ormation, print and fax this form with the completed credit card informati= on or mail it to the address below=2E Email: medicalsolution@hotmail=2Ecom Via Fax 1-209-391-8806 Or Mail to: H Beaver PMB 146, 270 Redwood Shores Parkway Redwood, CA 94065 BEGIN ORDER FORM --------------------------------------------------------------------------= ------------------ Please Send Me Lytec Medical 2001: Single-user version for $671=2E00 [ ] [US] Multi-user version for $971=2E00 [ ] [US] Professional version for $1,346=2E00 [ ] [US] Plus $15=2E00 S/H * - required Buyer/Shipping info: *Name: ______________________________________________________ *Company Name: ______________________________________________ *Shipping Address: _____________________________________________ *State/Province & Postal Code: ___________________________________ *Country: _____________________________________________________ *Telephone: ___________________________________________________ Fax: _________________________________________________________ *E-mail Address: _______________________________________________ *Card Type: MasterCard [ ] Visa [ ] AmEx [ ] Discover [ ] *Card Card Number: ____________________________________________ *Expiration Date: ______________________________________________ (If ordering with credit card, this must be returned with cardholder's sig= nature!) I authorize H=2EBeaver to charge my credit card for Lytec Medical 2001 in = the amount specified above=2E *Signature: ___________________________________________________ *Date: _______________________________________________________ *Name as appears on Card: _______________________________________ *Billing Address of credit card if different than shipping: City & Province/State & Postal Code: _____________________________________________________________ A CHECK payment delays your shipment by 5 Business Days for Clearance=2E Please fax the completed form to 1-209-391-8806 **************************************************************************= **************************************************************************= *********** This mailing is done by an independent marketing co=2E We apologize if thi= s message has reached you in error=2E To be removed please email medicalsolution@hotmail=2Ecom or Fax 1-209-391-8806 **************************************************************************= **************************************************************************= *********** From rodolfo@linux.org.uy Tue Aug 14 16:28:13 2001 From: rodolfo@linux.org.uy (Rodolfo Pilas) Date: Tue, 14 Aug 2001 12:28:13 -0300 Subject: [Mailman-Developers] Starting mailmanctl Message-ID: <20010814122813.7fb0fa56.rodolfo@linux.org.uy> The INSTALL v.2.1a2 document says: - Start the Mailman qrunner daemon, by executing the following from the $prefix directory: % bin/mailmanctl start You can use the mailmanctl script as a typical Unix init script. [BAW: add more here.] Ok, I started mailmanctl from the command line and all is working. But I started it from init.d/boot.local (SuSE 7.2) and I had problems. Can somebody explain me how to start this daemon (i.e. start at last, or if it requires some other services) to have it working into init level 3 (think that your reply may be included into INSTALL doc ;) -- ____________________________________________________ -=(( Rodolfo Pilas - rodolfo@linux.org.uy ))=- -==((( Are you ready for XtraLinuX - http://xtralinux.org )))==- -=((____________________________________________________))=- Guarde sus mail en Echelon: OLP, Greenpeace, ETA, Hamas, Hizbullah, FMI Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 From dgc@uchicago.edu Tue Aug 14 20:31:26 2001 From: dgc@uchicago.edu (David Champion) Date: Tue, 14 Aug 2001 14:31:26 -0500 Subject: [Mailman-Developers] Re: edit moderated messages? In-Reply-To: <25236.997812283@2wire.com> References: <001201c12400$487c4c30$3a28603f@CHERRYBLOSSOM> <18444.997730265@2wire.com> <20010813161225.J7893@smack.uchicago.edu> <19830.997741696@2wire.com> <20010813173707.P7893@smack.uchicago.edu> <19981.997743783@2wire.com> <20010813181412.S7893@smack.uchicago.edu> <25236.997812283@2wire.com> Message-ID: <20010814143126.G16110@smack.uchicago.edu> On 2001.08.14, in <25236.997812283@2wire.com>, "J C Lawrence" wrote: > > Not sure you meant this to be off-list. I did originally, since I didn't think my comment was good enough to waste everyone's time, just yours. :) Seems fair for the list now, though; I'm cc:ing, and giving my quotation scalpel a much-needed rest. List: this has to do with proposed features for moderated (read: editable) approval in admindb. I initially objected (privately) to JC's comment that editing the raw text was an advantage, on the grounds that it's not actually *that* useful for most moderators I know (and might be very confusing, to boot) -- but I agree with the principle that power for those who can wield it is good. Here's a common ground we arrived at. > On Mon, 13 Aug 2001 18:14:12 -0500 > David Champion wrote: > > On 2001.08.13, in <19981.997743783@2wire.com>, "J C Lawrence" > > wrote: > > >> How about: > >> > >> The edit interface by default exposes an editable text area for > >> each text/* parts in the message, and keep/delete radio buttons > >> for each of the non-text/* bits possibly along with an immutable > >> text representation. > >> > >> A further button can be hit to render the entire message in an > >> editable textarea. > > > That basically sounds good to me, as a first step. Ultimately I'd > > like to see it rendering certain attachment types, but there's no > > reason to demand this now in the absence of the same feature in > > the archiver. :) > > Quite. Also: I'd be happy enough never to have it; I just think it would be nifty if that ever did arrive. > > 1. I'd put keep/delete radios on the text parts, too -- it might > > not be obvious to Joe User that deleting all text in a textarea > > implies removal of the mime part, and it might be easier, too. > > > > > 2. Maybe another button on each non-text component would allow > > download of the decoded binary object. That might be a bit much to > > add in now, but it would be most useful for review purposes. "Is > > this an inappropriate image/jpeg attachment, or can I let it > > through?" Hard to know if all you see is base-64, and you don't > > have a MIME-spec base-64 decoder. > > A link which hits a CGI which returns the binary stream of the > base64 (if needed) processed blob would do just fine. If we want to > get *really* fancy we could then even do MIME types handling, but I > don't see that's worth bothering with initially. Yes, links are fine... I didn't really mean to limit it to a form element, and there's no reason I can see to do it that way. It works for me with or without content-types in the HTTP header -- I expect an octet-stream is sufficient for most cases, but MIME types might be nice for others. Actually it's probably not that hard to add, if you just assume (as Mailman ought) that the MIME header knows what it's talking about. -- -D. dgc@uchicago.edu NSIT University of Chicago From Dan Mick Tue Aug 14 21:23:22 2001 From: Dan Mick (Dan Mick) Date: Tue, 14 Aug 2001 13:23:22 -0700 (PDT) Subject: [Mailman-Developers] Starting mailmanctl Message-ID: <200108142023.NAA22257@utopia.West.Sun.COM> > Ok, I started mailmanctl from the command line and all is working. > > But I started it from init.d/boot.local (SuSE 7.2) and I had problems. How do you expect anyone to know what problems you had? And if they don't know what problems you had, how can they possibly solve them? You have to describe the problem to get an answer. > Can > somebody explain me how to start this daemon (i.e. start at last, or if it > requires some other services) to have it working into init level 3 (think > that your reply may be included into INSTALL doc ;) From rodolfo@linux.org.uy Tue Aug 14 23:07:05 2001 From: rodolfo@linux.org.uy (Rodolfo Pilas) Date: Tue, 14 Aug 2001 19:07:05 -0300 Subject: [Mailman-Developers] Starting mailmanctl In-Reply-To: <200108142023.NAA22257@utopia.West.Sun.COM> References: <200108142023.NAA22257@utopia.West.Sun.COM> Message-ID: <20010814190705.2a06176e.rodolfo@linux.org.uy> El Tue, 14 Aug 2001 13:23:22 -0700 (PDT) Dan Mick ha escrito: > > > Ok, I started mailmanctl from the command line and all is working. > > > > But I started it from init.d/boot.local (SuSE 7.2) and I had problems. > > How do you expect anyone to know what problems you had? And if they > don't know what problems you had, how can they possibly solve them? > > You have to describe the problem to get an answer. I really sorry, but the problem was that the mailmanctl is not in the ps list and when I mailmanctl start it says that "is allready running.." I stop it, but I allways has "is allredy running" as a reply of mailmanctl start. I understant that this is a problem of where I start the first time the mailmanctrl (at boot.local script). As I said, I restart the server and start mailmanctl from a command line and NOW ALL is working. As you understand I need to know where to start mailmanctl propertly. And then I ask: > > Can > > somebody explain me how to start this daemon (i.e. start at last, or > if it > > requires some other services) to have it working into init level 3 > (think > > that your reply may be included into INSTALL doc ;) For this reason I do not explained the problem, because I resolve it. But I need to improve my configuration. -- ____________________________________________________ -=(( Rodolfo Pilas - rodolfo@linux.org.uy ))=- -==((( Are you ready for XtraLinuX - http://xtralinux.org )))==- -=((____________________________________________________))=- Guarde sus mail en Echelon: OLP, Greenpeace, ETA, Hamas, Hizbullah, FMI Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 From barry@zope.com Wed Aug 15 07:43:43 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 15 Aug 2001 02:43:43 -0400 Subject: [Mailman-Developers] Starting mailmanctl References: <20010814122813.7fb0fa56.rodolfo@linux.org.uy> Message-ID: <15226.6687.382511.813746@anthem.wooz.org> >>>>> "RP" == Rodolfo Pilas writes: RP> But I started it from init.d/boot.local (SuSE 7.2) and I had RP> problems. Can somebody explain me how to start this daemon RP> (i.e. start at last, or if it requires some other services) to RP> have it working into init level 3 (think that your reply may RP> be included into INSTALL doc ;) It's likely that `python' is not on the default $PATH for boot.local. Does it work if you run /path/to/my/python /path/to/my/mailman/bin/mailmanctl start instead? mailmanctl uses a shebang line of /usr/bin/env to search for the python executable. I don't want to make mailmanctl autoconf generated, but JD Bronson donated a boot script that could be made autoconf'able. I'll check it for Linux compatibility tomorrow and check it in if it looks good. I'll let others check for compatibility on other *nixes. -Barry From jeff.covey@freshmeat.net Wed Aug 15 09:38:30 2001 From: jeff.covey@freshmeat.net (jeff covey) Date: Wed, 15 Aug 2001 04:38:30 -0400 Subject: [Mailman-Developers] freshmeat project listing for Mailman Message-ID: <200108150838.f7F8cUbh013246@jeffcovey.net> I'm writing in reference to your project "Mailman". Since the time you submitted this project to us, freshmeat has adopted a new categorization system which allows much more fine-grained organization of projects. Since your project has never been recategorized under this system, our readers aren't finding your project when they browse through categories where it should be listed. We'd like to ask you to take just a few minutes to recategorize your project. You should delete any categories which begin with "Old Appindex" and add all of the new categories which apply to your project. You can edit your project listing at: http://freshmeat.net/projects/mailman/ with the "recategorize" function in the menu. While you're there, take a moment to make sure everything else is up-to-date. If you have any problems, please let us know at http://freshmeat.net/contact/. Thanks for listing your project in our database. Sincerely, Jeff Covey From jim@aghall012.canr.msu.edu Wed Aug 15 18:34:59 2001 From: jim@aghall012.canr.msu.edu (jim@aghall012.canr.msu.edu) Date: Wed, 15 Aug 2001 13:34:59 -0400 Subject: [Mailman-Developers] Adding Cgi files in mailman Message-ID: <200108151734.f7FHYx500735@aghall012.canr.msu.edu> I am attempting to create multiple administrative pages for security reasons. One will remain unchanged and allow our department access to all mailing lists and options, and the other will be a modified version that disables such options as modifying maximum message size, editing of HTML user interfaces, etc. My problem is that I am unable to generate an object file to place within $prefix/mailman/cgi-bin. I have everything all worked out, except this problem is keeping me from viewing more pages than already exist within cgi-bin. What I would like to do it take a modified version of, for instance, the admin.py file (renamed ANRadmin.py) and create within the cgi-bin directory a file called ANRadmin that is analogous to the file admin that is alreay within cig-bin. I know that I must be missing something obvious, and I wouldn't be posting this if I hadn't already spent weeks on this project. (I had to familiarize myself with no only mailman but python and cgi scripts.) Any insight into this issue would be greatly appreciated. -Jim From dagilbert@west.raytheon.com Wed Aug 15 19:22:13 2001 From: dagilbert@west.raytheon.com (David A Gilbert) Date: Wed, 15 Aug 2001 11:22:13 -0700 Subject: [Mailman-Developers] archives not showing Re: in message subject Message-ID: Hope someone can help with this, haven't had any response on mailman-users list. Whenever users reply to a message sent out by list, the Re: Subject shows up when message is sent out to list, but when you look at the archives, it just has Subject. Archives show: Subject Subject Subject Instead of: Subject Re: Subject Re: Subject Running mailman on 2 systems, Redhat Linux 7.0, Mailman2.0.5, Postfix and another with RedHat Linux 6.2, Mailman2.0.6, and Sendmail and we see problem on both systems. Thanks in advance. David Gilbert dagilbert@west.raytheon.com From barry@zope.com Wed Aug 15 19:31:18 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 15 Aug 2001 14:31:18 -0400 Subject: [Mailman-Developers] Starting mailmanctl References: <200108142023.NAA22257@utopia.West.Sun.COM> <20010814190705.2a06176e.rodolfo@linux.org.uy> Message-ID: <15226.49142.691316.8430@anthem.wooz.org> >>>>> "RP" == Rodolfo Pilas writes: RP> I really sorry, but the problem was that the mailmanctl is not RP> in the ps list and when I mailmanctl start it says that "is RP> allready running.." I stop it, but I allways has "is allredy RP> running" as a reply of mailmanctl start. RP> I understant that this is a problem of where I start the first RP> time the mailmanctrl (at boot.local script). As I said, I RP> restart the server and start mailmanctl from a command line RP> and NOW ALL is working. I'm getting the exact same behavior on my RH6.1-ish system. So something weird is definitely going on. -Barry From claw@kanga.nu Wed Aug 15 20:12:40 2001 From: claw@kanga.nu (J C Lawrence) Date: Wed, 15 Aug 2001 12:12:40 -0700 Subject: [Mailman-Developers] Re: Mailman, Majordomo, & MHonArc (fwd) In-Reply-To: Message from Eric Pretorious of "Mon, 13 Aug 2001 23:41:07 PDT." References: Message-ID: <14122.997902760@kanga.nu> <> On Mon, 13 Aug 2001 23:41:07 -0700 (PDT) Eric Pretorious wrote: > On Mon, 13 Aug 2001, J C Lawrence wrote: >> What are your problems? > 1. Basic Administration What sorts of things should I be > looking/preparing for? Necessary actions fall into three categories: 1) Initial configuration of Mailman, your MTA, and any lists 2) Ongoing monitoring of Mailman operations for correctness and desired behaviour. 3) Maintenance and tuning of your installation. Mailman install is pretty well documented at this point. MTA configuration, depending on your MTA, can be a bit of a pain, especially if you have performance or scalability requirements. monitoring is a question of logfile analysis (logcheck can be a big blessing here). Maintenance and tuning just the normal slow incremental tinkering thing. Side notes: Install a local cacheing name server. Configure your MTA to not do DNS checks on messages delivered from localhost. In the beginning set your MTA for max logging. Turn it down later when things are working well. Configure Mailman to deliver via SMTP not sendmail invocations. Don't use sendmail. If you're new to mail systems and/or want a pleasant learning curve, use Exim. If you have stringent performance or security model requirements, use Postfix (which is not to say that Exim is not fast or secure, it is in fact very fast and secure, but the model is different). If you use Exim, Nigel Metherington (sp?) has written a very good HOWTO available at exim.org. Read the READMEs. > I'll probably find good answers to this in the book and from "just > doing it." I can't comment on the book. Unless you're headed into scalability areas, its all pretty damned simple really. If you're interested in the scalability ends, search the Mailman archives for posts with both my and Chuq Von Rospach's name in them, and then check those threads. Chuq and I (and several others, but Chuq and I retrospectively seem the one guaranteed common key) have had several good discussions here on mail system configuration and tuning. > 2. Virtual Domains Can a single installation of Mailman (i.e., > pipermail) _archive_ multiple domains, each with it's own HTML > layout? Yes, Mailman can archive multiple virtual domains. No, Pipermail currently has no supports for customisation of the archive HTML. This is one of the reasons many people use external archivers like MHonArc (and proper MIME handling, charset handling, etc etc etc). > 3. Customizing Archive Layouts The very small amount of > information that I've found would suggest that I abandon Pipermail > and switch to MHonArc. Pipermail has no HTML configuration support other than directly editing the pipermail sources. Its a great starter system, works well for that, and keeps it archives in a format that is easy to migrate to something more capable. >> Generally, don't bother. Pipermail, Mailman's archiver, is >> feature poor at best. It works for a very minimal version of >> work. I recommend using an external archiver ala MHonArc (its >> what I do). > How did you substitute MHonArc for Pipermail? Did you configure > MHonArc as a cron job; Modify the wrapper script; Place a `tee > mhonarc` command in the aliases.db; Or is there an obvious answer > to this? You can tell Mailman to use MHonArc as an external archiver directly as part of your Mailman configuration. There has been discussion of this on the Mailman lists recently. I'm not familiar with the details as I don't do that. See the archives. What I do is to subscribe an external account to the lists I want to archive. I then have an assortment of procmail recipies and cron jobs which do the right thing with the messages such that they are archives as you see at Kanga.Nu. One of the specific reasons I chose this approach is that I wanted the same mechanism for locally hosts lists as well as my archives of remote lists. > Since you've replaced the archiving functionality, why have you > chosen to stay with Mailman instead of one of the others: > Majordomo, LISTSERV, ListProc, or SmartList? It works. It does what I need/want. It offers the features my users need/want. It scales and performs reasonably well. Its both Open Source and actively maintained. The only other MLM I'm aware of that reasonably matches is Sympa. Feature wise Mailman and Sympa are comparable with each offering a few features and capabilities the other doesn't. The fact that Sympa is written in perl I consider a huge drawback compared to Mailman's Python. > Is it the administrative web-interface? Its certainly pleasant and appreciated. Other MLMs have similar. -- J C Lawrence )\._.,--....,'``. ---------(*) /, _.. \ _\ ;`._ ,. claw@kanga.nu `._.-(,_..'--(,_..'`-.;.' http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly From barry@zope.com Wed Aug 15 20:25:04 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 15 Aug 2001 15:25:04 -0400 Subject: [Mailman-Developers] Starting mailmanctl References: <20010814122813.7fb0fa56.rodolfo@linux.org.uy> Message-ID: <15226.52368.71304.64938@anthem.wooz.org> >>>>> "RP" == Rodolfo Pilas writes: RP> But I started it from init.d/boot.local (SuSE 7.2) and I had RP> problems. I'm about to check in misc/S98mailman which works now for me on my RedHat 6.1-ish Linux box. No guarantees for any other Linux distros let along other *nixes. Wait for checkins to mailmanctl (and INSTALL). -Barry From barry@zope.com Wed Aug 15 21:47:39 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 15 Aug 2001 16:47:39 -0400 Subject: [Mailman-Developers] current snapshot startup woes References: <200107260749.f6Q7n4s06438@babylon5.cc.vt.edu> Message-ID: <15226.57323.601721.641828@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> FYI, I built and installed the current snapshot on my test RJ> machine (which did have a couple of articles lying around in RJ> the queues that were never delivered when I last stopped RJ> qrunner...) RJ> Doing a mailmanctl start got me page after page of this... [snip] Ron, were you upgrading from MM2.0.x to MM2.1, or from an earlier 2.1 snapshot to a later 2.1 snapshot? Were the undelivered files sitting at the top level under qfiles or were they in a subdirectory of qfiles? If the former, did you move them? -Barry From jarrell@vt.edu Wed Aug 15 21:52:46 2001 From: jarrell@vt.edu (Ron Jarrell) Date: Wed, 15 Aug 2001 16:52:46 -0400 Subject: [Mailman-Developers] current snapshot startup woes In-Reply-To: <15226.57323.601721.641828@anthem.wooz.org> References: <200107260749.f6Q7n4s06438@babylon5.cc.vt.edu> Message-ID: <5.1.0.14.2.20010815164838.04bd7df0@lennier.cc.vt.edu> At 04:47 PM 8/15/01 -0400, Barry A. Warsaw wrote: >>>>>> "RJ" == Ron Jarrell writes: > > RJ> FYI, I built and installed the current snapshot on my test > RJ> machine (which did have a couple of articles lying around in > RJ> the queues that were never delivered when I last stopped > RJ> qrunner...) > > RJ> Doing a mailmanctl start got me page after page of this... > >[snip] > >Ron, were you upgrading from MM2.0.x to MM2.1, or from an earlier 2.1 >snapshot to a later 2.1 snapshot? Were the undelivered files sitting >at the top level under qfiles or were they in a subdirectory of >qfiles? If the former, did you move them? Oh, yea, you'd ask me these detailed questions *now* when I've had eight gazillion crises du jour run in one ear, out the other, and floss all the unneeded bits in between... It was from an earlier 2.1 snapshot to the then current 2.1 snapshot. I'm pretty sure they were sitting in the top level. They might well have been undelivered messages from when I attempted to test one of the very early 2.1 snapshots, and discovered that qrunner didn't work worth a damn all of a sudden - most of the various sub runners were blowing up in my face. I left it dropped like that for a few weeks, and all the work I did on 2.1 at that point were tracking those various errors with templates and such; I didn't actually let the system try to process mail after that. From barry@zope.com Wed Aug 15 21:55:32 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 15 Aug 2001 16:55:32 -0400 Subject: [Mailman-Developers] current snapshot startup woes References: <200107260749.f6Q7n4s06438@babylon5.cc.vt.edu> <5.1.0.14.2.20010815164838.04bd7df0@lennier.cc.vt.edu> Message-ID: <15226.57796.352796.412222@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> Oh, yea, you'd ask me these detailed questions *now* when I've RJ> had eight gazillion crises du jour run in one ear, out the RJ> other, and floss all the unneeded bits in between... Heh, you too? Me too! RJ> It was from an earlier 2.1 snapshot to the then current 2.1 RJ> snapshot. I'm pretty sure they were sitting in the top level. RJ> They might well have been undelivered messages from when I RJ> attempted to test one of the very early 2.1 snapshots, and RJ> discovered that qrunner didn't work worth a damn all of a RJ> sudden - most of the various sub runners were blowing up in my RJ> face. I left it dropped like that for a few weeks, and all RJ> the work I did on 2.1 at that point were tracking those RJ> various errors with templates and such; I didn't actually let RJ> the system try to process mail after that. Okay, I'm going to latch onto that like a gator, so I'm not going to worry about it as much as making sure that unprocessed MM2.0.x messages get handled correctly. Thanks, -Barry From mentor@alb-net.com Thu Aug 16 00:50:41 2001 From: mentor@alb-net.com (Mentor Cana) Date: Wed, 15 Aug 2001 19:50:41 -0400 (EDT) Subject: [Mailman-Developers] grouping/categorizing the lists? (wish list item) Message-ID: Here is a wish list item. Barry, how easy will it be to enable grouping/categorizing the lists on the mailman/listinfo page? The mailman/site admin determines and predefines set of groupings (categories) that are relevant and pertinent to the site. Then, upon the lists creation (and for the already created lists) the list admin can chose which category their lists should be listed under, or maybe even let the list admin 'check' more then one relevant category. Lists that have not chosen a category should be listed under the 'General' category. I know this might not mean much to many site admins, however, it is a great feature to have on mailman as many mailman sites are running multiple lists and many many sites are replacing their existing list management software with Mailman. -- Mentor From Tom Eagle" Message-ID: <002201c12601$cba203e0$6401a8c0@sprintion.com> Barry, See there a way to include the sender's subject line in the auto-response text? Tom Eagle From barry@zope.com Thu Aug 16 05:25:14 2001 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 16 Aug 2001 00:25:14 -0400 Subject: [Mailman-Developers] How to rename a list References: <5.1.0.14.2.20010718105036.03294b88@mailhost.atext.com> <5.1.0.14.2.20010724162112.077723d0@mailhost.atext.com> <5.1.0.14.2.20010725102106.03df3e80@mailhost.atext.com> Message-ID: <15227.19242.722021.175539@anthem.wooz.org> A while ago Michael asked about the canonical way to rename a mailing list. Turns out that I had to do this for one of the zope.org lists, although I didn't get to it before my vacation. As an exercise I decided to write up the steps as a FAQ entry, then move the zope.org list and see how close I got. I was suprised that I didn't have to change a thing, but the real test will be for one of you to try to follow the recipe and find the gotchas. I append the FAQ entry below. It looks imposing, and that's enough of a reason why the current situation sucks, but renaming a list just isn't a common enough task IMO that it's worth spending time improving for MM2.1. Let's put it on the slate for the next version, though. And though it seems like a lot of stuff, it really isn't. I was able to follow the instructions and rename the list in about 5 minutes. There's a lot of detail because you want to be as cautious as possible so that no posts or web hits are reaching the list until the move is complete. Comments, questions? -Barry (P.S. Michael, I hope this helps!) -------------------- snip snip -------------------- Q. How do I rename a list? A. Renaming a list is currently a bit of a pain to do completely correctly, especially if you want to make sure that the old list contacts are automatically forwarded to the new list. This ought to be easier. :( The biggest problem you have is how to stop mail and web traffic to your list during the transition, and what to do about any mail undelivered to the old list after the move. I don't think there are any foolproof steps, but here's how you can reduce the risk: - Temporarily disable qrunner. To do this, you need to edit the user `mailman's crontab entry. Execute the following command, commenting out the qrunner line when you're dropped into your editor. Then save the file and quit the editor. % crontab -u mailman -e - Turn off your mail server. This is mostly harmless since remote MTAs will just keep retrying until you turn it back on, and it's not going to be off for very long. - Next turn off your web server if possible. This of course means your entire site will be off-line while you make the switch and this may not be acceptable to you. The next best suggestion is to set up your permanent redirects now for the list you're moving. This means that anybody looking for the list under its old name will be redirected to the new name, but they'll get errors until you've completed the move. Let's say the old name is "oldname" and the new name is "newname". Here are some Apache directives that will do the trick, though YMMV: RedirectMatch permanent /mailman/(.*)/oldname(.*) http://www.dom.ain/mailman/$1/newname$2 RedirectMatch permanent /pipermail/oldname(.*) http://www.dom.ain/pipermail/newname$1 Add these to your httpd.conf file and restart Apache. - Now cd to the directory where you've installed Mailman. Let's say it's /usr/local/mailman: % cd /usr/local/mailman and cd to the `lists' subdirectory: % cd lists You should now see the directory `oldname'. Move this to `newname': % mv oldname newname - Now cd to the private archives directory: % cd ../archives/private You will need to move the oldname's .mbox directory, and the .mbox file within that directory. Don't worry about the public archives; the next few steps will take care of them without requiring you to fiddle around in the file system: % mv oldname.mbox newname.mbox % mv newname.mbox/oldname.mbox newname.mbox/newname.mbox - You now need to run the `bin/move_list' script to update some of the internal archiver paths. IMPORTANT: Skip this step if you are using Mailman 2.1! % cd ../.. % bin/move_list newname - You should now regenerate the public archives: % bin/arch newname - You'll likely need to change some of your list's configuration options, especially if you want to accept postings addressed to the old list on the new list. Visit the admin interface for your new list: o Go to the General options o Change the "real_name" option to reflect the new list's name, e.g. "Newname" o Change the subject prefix to reflect the new list's name, e.g. "[Newname] " (yes, that's a trailing space character). o Optionally, update other configuration fields like info, description, or welcome_msg. YMMV. o Save your changes o Go to the Privacy options o Add the old list's address to acceptable_aliases. E.g. "oldname@dom.ain". This way, (after the /etc/aliases changes described below) messages posted to the old list will not be held by the new list for "implicit destination" approval. o Save your changes - Now you want to update your /etc/aliases file to include the aliases for the new list, and forwards for the old list to the new list. Note that these instructions are for Sendmail style alias files, adjust to the specifics of how your MTA is set up. o Find the lines defining the aliases for your old list's name o Copy and paste them just below the originals. o Change all the references of "oldname" to "newname" in the pasted stanza. o Now change the targets of the original aliases to forward to the new aliases. When you're done, you will end up with /etc/aliases entries like the following (YMMV): # Forward the oldname list to the newname list oldname: newname@dom.ain oldname-request: newname-request@dom.ain oldname-admin: newname-admin@dom.ain oldname-owner: newname-owner@dom.ain newname: "|/usr/local/mailman/mail/wrapper post newname" newname-admin: "|/usr/local/mailman/mail/wrapper mailowner newname" newname-request: "|/usr/local/mailman/mail/wrapper mailcmd newname" newname-owner: newname-admin o Run newaliases - Before you restart everything, you want to make one last check. You're looking for files in the qfiles/ directory that may have been addressed to the old list but weren't delivered before you renamed the list. Do something like the following: % cd /usr/local/mailman/qfiles % grep oldname *.msg If you get no hits, skip to the next step, you've got nothing to worry about. If you did get hits, then things get complicated. I warn you that the rest of this step is untested. :( For each of the .msg files that were destined for the old list, you need to change the corresponding .db file. Unfortunately there's no easy way to do this. Anyway... Save the following Python code in a file called 'hackdb.py': -------------------------hackdb.py import sys import marshal fp = open(sys.argv[1]) d = marshal.load(fp) fp.close() d['listname'] = sys.argv[2] fp = open(sys.argv[1], 'w') marshal.dump(d, fp) fp.close() ------------------------- And then for each file that matched your grep above, do the following: % python hackdb.py reallylonghexfilenamematch1.db newname - It's now safe to turn your MTA back on. - Turn your qrunner back on by running % crontab -u mailman -e again and this time uncommenting the qrunner line. Save the file and quit your editor. - Rejoice, you're done. Send $100,000 in shiny new pennies to the Mailman cabal as your downpayment toward making this easier for the next list you have to rename. :) From m.mohr@johalla.de Thu Aug 16 12:58:06 2001 From: m.mohr@johalla.de (Markus Mohr) Date: Thu, 16 Aug 2001 13:58:06 +0200 Subject: [Mailman-Developers] autoreply loops, Mailman 1.1 References: <3B7A47DD.943F3A41@johalla.de> Message-ID: <3B7BB54E.293CFFF4@johalla.de> Hi! I'm running Mailman 1.1 on Debian/stable and had the following problem: The list is a discussion list and so is set to reply-to list. One of the subscribers has set up an auto-responder which created a mail loop. Ok, one fault on his side was to not configure this autoresponder, but there is another thing which looks strange to me: the answers from the responder included: [..] X-Autoreply-From: [..] Precedence: bulk [..] X-BeenThere: [..] If I understood correctly each of this lines should have stopped mailman from resending his answer to the list!? It didn't though and so created a lot of unwanted mails. :( I couldn't find a trigger in the configuration to change this behaviour. thanks for your help marksu P.S.: please cc answers to me as I'm not subscribed to this list From rlo@perforce.com Thu Aug 16 19:38:27 2001 From: rlo@perforce.com (Robert Orenstein) Date: Thu, 16 Aug 2001 11:38:27 -0700 Subject: [Mailman-Developers] Mailman design doc Message-ID: <3.0.1.32.20010816113827.00a80d90@pop> Hi, all. Is there any kind of basic Mailman design document describing the structure of the code, or even just pointing to the 7 or 8 basic Mailman source files? I've been teaching our tech support people how to code in Python, and since we use Mailman, we thought we might spend a couple of months at the end of the workshop looking at Mailman and making a few changes that we'd like to have on-site. But without any kind of roadmap, this is tough. Any thoughts on this would be appreciated. Thanks, Robert Orenstein Perforce Software From wilane@yahoo.com Thu Aug 16 23:04:50 2001 From: wilane@yahoo.com (Ousmane Wilane) Date: Thu, 16 Aug 2001 22:04:50 +0000 Subject: [Mailman-Developers] Re: Starting mailmanctl Message-ID: <15228.17282.453597.281340@localhost.localdomain> Hi, IMHO, we'd better let `chkconfig' manage /etc/rc.d dir hier for few reasons: 1- The various symlinks in /etc/rc.d are managed by `chkconfig' on modern rpm based system, IRIX, etc. 2- The informations needed by chkconfig are commented line on top of the init file like: # mailmanctl: 2345 98 12 # description: The cabal pandora's box. thus, other systems can safely use the same init file. 3- We just have to rename the filez (letting the cabal happy 8) and add few commented line on the top. 4- Make rpm, deb packaging easy. 5- I think that Mailman endeavors to be compatible with standards (/get/ thingy hehe 8). On my RH6.2-ish I have: [dummy@nowhere]$ rpm -qi chkconfig ... Chkconfig is a basic system utility. It updates and queries runlevel information for system services. Chkconfig manipulates the numerous symbolic links in /etc/rc.d, to relieve system administrators of some of the drudgery of manually editing the symbolic links. >From man page: chkconfig provides a simple command-line tool for main- taining the /etc/rc.d directory hierarchy by relieving system administrators of the task of directly manipulating the numerous symbolic links in those directories." If all those moronic things make you cringe, plz forget about them :) If that's the way to go, we can add to the doc sth like: If you use sysvinit/chkconfig, copy the mailmanctl init file to /etc/init.d/ (FHS thingy I think) and run: $ chkconfig --add mailmanctl $ chkconfig mailmanctl on My 5 FCFA! Cheers. -- Ousmane Wilane (http://purl.org/NET/WILANE) Libérez Dimitry Sklyarov! http://www.freesklyarov.org From claw@kanga.nu Thu Aug 16 23:27:00 2001 From: claw@kanga.nu (J C Lawrence) Date: Thu, 16 Aug 2001 15:27:00 -0700 Subject: [Mailman-Developers] Re: Starting mailmanctl In-Reply-To: Message from Ousmane Wilane of "Thu, 16 Aug 2001 22:04:50 -0000." <15228.17282.453597.281340@localhost.localdomain> References: <15228.17282.453597.281340@localhost.localdomain> Message-ID: <7962.998000820@kanga.nu> On Thu, 16 Aug 2001 22:04:50 +0000 Ousmane Wilane wrote: > Hi, IMHO, we'd better let `chkconfig' manage /etc/rc.d dir hier > for few reasons: > 1- The various symlinks in /etc/rc.d are managed by `chkconfig' on > modern rpm based system, IRIX, etc. This is not true for Debian, and other .deb based Linux distributions. Its also not true for Solaris, HP-UX, AIX, and several other commercial *ixes. > 2- The informations needed by chkconfig are commented line on top > of the init file like: # mailmanctl: 2345 98 12 # description: The > cabal pandora's box. thus, other systems can safely use the same > init file. chkconfig under IRIX works considerably differently in regard to how it controls RC files. In fact the Linux chkconfig tool is inspired by the IRIX chkconfig, but only bears minimal similarity to it. > 4- Make rpm, deb packaging easy. 5- I think that Mailman > endeavors to be compatible with standards (/get/ thingy hehe 8). This is already easy in the general case. This is not to say that chkconfig-style comments shouldn't be embedded in the init script, just that depending on those supports is likely not wise. -- J C Lawrence )\._.,--....,'``. ---------(*) /, _.. \ _\ ;`._ ,. claw@kanga.nu `._.-(,_..'--(,_..'`-.;.' http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly From Simon.Atack@atackscomputers.co.uk Thu Aug 16 23:53:02 2001 From: Simon.Atack@atackscomputers.co.uk (Simon Atack) Date: Thu, 16 Aug 2001 22:53:02 -0000 (GMT) Subject: [Mailman-Developers] mailman 2.1a2 -- mailmanctl -- memory usage Message-ID: <61109.62.252.176.103.998002382.squirrel@webmail.atackscomputers.co.uk> I have recently installed mailman 2.1a2 on my test server. On this there are around a dozen virtual domains. I am running exim as MTA. I have used the examples given with mailman for exim, the last part with a seperate installation of mailman for each virtual domain (since several have lists of the same name). The problem occurs because running mailmanctl start once for each domain, runs 7 python ./mailmanctl start that use around 3.4Mb each. after several the machine started to use vast quantities of ram so i didnt upgrade the rest of the test lists. Is there any way of reducing the memory foot print of each of these runners, or maybe just run 1 instead of 7? Is it possible to somehow go back to doing it the old way via a cron job? as the machine didnt have a problem running these -- Simon Atack ----------------------------------------- This email was sent using SquirrelMail. "Webmail for nuts!" http://squirrelmail.org/ From wilane@yahoo.com Fri Aug 17 00:01:24 2001 From: wilane@yahoo.com (Ousmane Wilane) Date: Thu, 16 Aug 2001 23:01:24 +0000 Subject: [Mailman-Developers] Re: Starting mailmanctl In-Reply-To: <7962.998000820@kanga.nu> References: <15228.17282.453597.281340@localhost.localdomain> <7962.998000820@kanga.nu> Message-ID: <15228.20676.371595.428432@localhost.localdomain> >>>>> "JCL" == J C Lawrence writes: JCL> This is not true for Debian, and other .deb based Linux JCL> distributions. Its also not true for Solaris, HP-UX, AIX, JCL> and several other commercial *ixes. Right! (In fact I don't remember my post allegating the contrary :) JCL> chkconfig under IRIX works considerably differently in regard JCL> to how it controls RC files. In fact the Linux chkconfig JCL> tool is inspired by the IRIX chkconfig, but only bears JCL> minimal similarity to it. 100% agreed also! JCL> This is not to say that chkconfig-style comments shouldn't be JCL> embedded in the init script, just that depending on those JCL> supports is likely not wise. Depending on it? Hell NO! But why don't we make things work under most sys (even the worse) using there tools? What I would like to know is: What do we break adding chkconfig style comment to the init file, perhaps I'm missing spmething? And to make the point clear, I'm definitely not one of the chkconfig's fan. Cheers -- Ousmane Wilane (http://purl.org/NET/WILANE) Libérez Dimitry Sklyarov! http://www.freesklyarov.org From barry@zope.com Fri Aug 17 17:20:14 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 17 Aug 2001 12:20:14 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] postfix alias mailman 2.1a2 References: <20010810144414.2f0e1175.rodolfo@linux.org.uy> <3B5FDF00.C7F6244D@mercatis.de> <15223.22195.514236.437151@anthem.wooz.org> <20010813134707.05eb9fa7.rodolfo@linux.org.uy> Message-ID: <15229.17470.31883.153107@anthem.wooz.org> >>>>> "RP" == Rodolfo Pilas writes: >> I'm not able to reproduce this particular crash. When I follow >> the directions in README.POSTFIX, everything works fine. Could >> we be hitting a library mismatch between the version of bsddb >> linked to Postfix and the one linked to Python? If so, that >> could make this approach fairly dicey. RP> Well, I fix the problem with these commands: | 1) touch mailman/data/aliases | (give the file the gid and access as README.POSTFIX) | 2) postalias hash:mailman/data/aliases | (this command creates an aliases.db) I think I have some better guidelines now. I realized that bin/genaliases can be used to initialize data/aliases.db (with a chown afterwards). Attached is the new README.POSTFIX instructions. This works for me from a virgin install, so it would be great if others could try it out. RP> Because I run postfix as nobody:nogroup I need to configure RP> mailman with --with-mail-gid=nogroup as a difference of RP> README.POSTFIX said. Hmm, I believe the key thing here is the ownership of the data/aliases.db file, regardless of how you start Postfix. I believe that Postfix will always run filter programs with the same uid as the owner of the aliases.db file, in this case user `mailman'. Thus you need to configure Mailman with --with-mail-gid=mailman as the instructions now clearly state that the owner of the data/aliases* files must be mailman.mailman. RP> Now I have all system working. An I wish to thank all of the RP> help received in mailman-users and mailman-developers RP> lists. THANK YOU! Excellent! -Barry From laloc@cats.ucsc.edu Fri Aug 17 19:13:27 2001 From: laloc@cats.ucsc.edu (Lalo Castro) Date: Fri, 17 Aug 2001 11:13:27 -0700 Subject: [Mailman-Developers] Error with OpenBSD 2.9 Message-ID: <3B7D5EC7.447EE0E5@cats.ucsc.edu> Hello, I am using an OpenBSD2.9 server with Mailman 2.0.6 and Python 1.5.2. Recently our main server was infected and this OpenBSD machine designated as the replacement for the mailman functions of the previous server. The install of Mailman, python, and OpenBSD are all fresh. Unfortunately, the transition from RH 6.0 to OpenBSD did not go as smoothly as thought. The Mailman administrator screen produces a "bug found" screen when the submit button is pressed. When we return to the administration screen and reload, the mail is designated as lost. All authentication and mails are proceeding as it should be. It is merely the deferred mails requiring administrative attention that produces an error. Has anyone encountered this before? If anyone has information that can help, please let me know. The error log follows. Thanks, Lalo Castro @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ admin(25612): [----- Mailman Version: 2.0.6 -----] admin(25612): [----- Traceback ------] admin(25612): Traceback (innermost last): admin(25612): File "/home/mailman/scripts/driver", line 96, in run_main admin(25612): main() admin(25612): File "../Mailman/Cgi/admindb.py", line 116, in main admin(25612): mlist.Save() admin(25612): File "/home/mailman/Mailman/MailList.py", line 860, in Save admin(25612): self.SaveRequestsDb() admin(25612): File "/home/mailman/Mailman/ListAdmin.py", line 93, in SaveRequestsDb admin(25612): self.__closedb() admin(25612): File "/home/mailman/Mailman/ListAdmin.py", line 80, in __closedb admin(25612): fp = open(self.__filename, 'w') admin(25612): IOError: [Errno 13] Permission denied: '/home/mailman/lists/element/request.db' admin(25612): [----- Python Information -----] admin(25612): sys.platform = openbsd2 admin(25612): [----- Environment Variables -----] admin(25612): DOCUMENT_ROOT: /web/html admin(25612): SERVER_ADDR: 128.114.163.14 admin(25612): HTTP_ACCEPT_ENCODING: gzip, deflate admin(25612): CONTENT_LENGTH: 22 admin(25612): CONTENT_TYPE: application/x-www-form-urlencoded admin(25612): PATH_TRANSLATED: /web/html/element admin(25612): SERVER_SOFTWARE: Apache/1.3.19 (Unix) admin(25612): GATEWAY_INTERFACE: CGI/1.1 admin(25612): HTTP_ACCEPT_LANGUAGE: en-us admin(25612): REMOTE_ADDR: 128.114.25.116 admin(25612): SERVER_PORT: 80 admin(25612): HTTP_CONNECTION: Keep-Alive admin(25612): HTTP_USER_AGENT: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) admin(25612): HTTP_ACCEPT: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-quickviewplus, application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, application/pdf, */* admin(25612): REQUEST_URI: /mailman/admindb/element admin(25612): HTTP_CACHE_CONTROL: no-cache admin(25612): QUERY_STRING: admin(25612): SERVER_PROTOCOL: HTTP/1.1 admin(25612): PATH_INFO: /element admin(25612): HTTP_HOST: library.ucsc.edu admin(25612): REQUEST_METHOD: POST admin(25612): SERVER_SIGNATURE:

Apache/1.3.19 Server at library.ucsc.edu Port 80
From tollef@add.no Fri Aug 17 19:45:27 2001 From: tollef@add.no (Tollef Fog Heen) Date: 17 Aug 2001 20:45:27 +0200 Subject: [Mailman-Developers] Error with OpenBSD 2.9 In-Reply-To: <3B7D5EC7.447EE0E5@cats.ucsc.edu> References: <3B7D5EC7.447EE0E5@cats.ucsc.edu> Message-ID: <87wv4234qg.fsf@arabella.intern.opera.no> * Lalo Castro | admin(25612): File "/home/mailman/Mailman/ListAdmin.py", line 80, in | __closedb | admin(25612): fp = open(self.__filename, 'w') | admin(25612): IOError: [Errno 13] Permission denied: | '/home/mailman/lists/element/request.db' What are the permissions of /home/mailman/lists/element/request.db ? -- Tollef Fog Heen You Can't Win From laloc@cats.ucsc.edu Fri Aug 17 20:11:11 2001 From: laloc@cats.ucsc.edu (Lalo Castro) Date: Fri, 17 Aug 2001 12:11:11 -0700 Subject: [Mailman-Developers] Error with OpenBSD 2.9 References: <3B7D5EC7.447EE0E5@cats.ucsc.edu> <87wv4234qg.fsf@arabella.intern.opera.no> Message-ID: <3B7D6C4F.706CFBA1@cats.ucsc.edu> -rw-r--r-- 1 root mailman Tollef Fog Heen wrote: > * Lalo Castro > > | admin(25612): File "/home/mailman/Mailman/ListAdmin.py", line 80, in > | __closedb > | admin(25612): fp = open(self.__filename, 'w') > | admin(25612): IOError: [Errno 13] Permission denied: > | '/home/mailman/lists/element/request.db' > > What are the permissions of /home/mailman/lists/element/request.db ? > > -- > > Tollef Fog Heen > You Can't Win > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers From barry@zope.com Fri Aug 17 20:23:55 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 17 Aug 2001 15:23:55 -0400 Subject: [Mailman-Developers] Error with OpenBSD 2.9 References: <3B7D5EC7.447EE0E5@cats.ucsc.edu> <87wv4234qg.fsf@arabella.intern.opera.no> <3B7D6C4F.706CFBA1@cats.ucsc.edu> Message-ID: <15229.28491.221760.601658@anthem.wooz.org> >>>>> "LC" == Lalo Castro writes: LC> -rw-r--r-- 1 root mailman Make that file 664 (i.e. group writable). Did bin/check_perms not catch this? -Barry From listmgr@perilpoint.com Fri Aug 17 21:03:50 2001 From: listmgr@perilpoint.com (Bradford Shaw) Date: Fri, 17 Aug 2001 15:03:50 -0500 Subject: [Mailman-Developers] SPAM filtering problem Message-ID: <4.2.0.58.20010817150301.00a72880@perilpoint.com> Hello, With the recent spam filtering methods that MSN, Hotmail, Yahoo, AOL, etc. email services are implementing to filter mailing list mail into bulk folders or worse, we need to quickly come up with some counter-procedures to get our customers' opt-in list subscribers receiving their mail again. A couple things that we would like to implement are: (1) removing the Precedence: bulk header or changing it to something like 'private' or 'registered' (2) to have the To: header addressed to the receiver instead of the list address How or where would we make these changes? I tried changing the CookHeaders.py but ended up blowing the delivery away. I ended up with over 200 X-BeenThere: headers on a test list. I don't know why that happened but I'm not going to worry about it right now. The most important thing is to get the filtering problem solved. Can anyone help? Best wishes, Bradford "Biff" Shaw List Administrator PerilPoint Communications Inc. http://www.perilpoint.com From howanitz@nindo.com Fri Aug 17 21:29:37 2001 From: howanitz@nindo.com (Keith Howanitz) Date: Fri, 17 Aug 2001 15:29:37 -0500 (CDT) Subject: [Mailman-Developers] SPAM filtering problem In-Reply-To: <4.2.0.58.20010817150301.00a72880@perilpoint.com> Message-ID: I need this header for proper behavior of other programs on my systems. I don't think it is fair to break other systems because some individuals feel those systems are inconvenient. Hotmail and other systems have options in their filters that will prevent mail sent from certain addresses (like your list) from being filtered (it's called the "Safe List" in Hotmail.) Maybe you should instruct your users to use this feature. -- -Keith howanitz@nindo.com On Fri, 17 Aug 2001, Bradford Shaw wrote: > Hello, [....] > > (1) removing the Precedence: bulk header > or changing it to something like 'private' or 'registered' [SNIP] From laloc@cats.ucsc.edu Fri Aug 17 21:29:31 2001 From: laloc@cats.ucsc.edu (Lalo Castro) Date: Fri, 17 Aug 2001 13:29:31 -0700 Subject: [Mailman-Developers] Error with OpenBSD 2.9 resolved Message-ID: <3B7D7EAB.55854D9D@cats.ucsc.edu> Thanks for the help! It indeed turned out to be a permissions problem. The lists' directories needed to have at least 664 access on the directories and the files in them. The /bin/check_perms set the permissions to be too strict (440). Thank you very much for the aid! Lalo Castro From barry@zope.com Fri Aug 17 21:39:47 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 17 Aug 2001 16:39:47 -0400 Subject: [Mailman-Developers] Error with OpenBSD 2.9 resolved References: <3B7D7EAB.55854D9D@cats.ucsc.edu> Message-ID: <15229.33043.98829.345973@anthem.wooz.org> >>>>> "LC" == Lalo Castro writes: LC> Thanks for the help! It indeed turned out to be a permissions LC> problem. The lists' directories needed to have at least 664 LC> access on the directories and the files in them. The LC> /bin/check_perms set the permissions to be too strict (440). Hmm, must be a MM2.0 thang. :) MM2.1's check_perms makes sure that the file is at least 660. -Barry From dsp@waterspout.com Fri Aug 17 21:40:37 2001 From: dsp@waterspout.com (Doug Porter) Date: Fri, 17 Aug 2001 15:40:37 -0500 Subject: [Mailman-Developers] Re: SPAM filtering problem In-Reply-To: Your message of "Fri, 17 Aug 2001 15:03:50 EST." <4.2.0.58.20010817150301.00a72880@perilpoint.com> References: <4.2.0.58.20010817150301.00a72880@perilpoint.com> Message-ID: <20010817204158.2641E9B13@squall.waterspout.com> Bradford Shaw wrote: > > With the recent spam filtering methods that MSN, Hotmail, > Yahoo, AOL, etc. email services are implementing to filter > mailing list mail into bulk folders or worse, Are they really filtering based on `Precedence: bulk' and calling it spam? I doubt many spammers are polite enough to add that header. ;P If they are only placing it into a bulk folder though and not calling it spam that seems like an okay thing to do. :/ I beleive both of your issues were previously discussed on the list though so you might want to dig into the archives if you are interested in past discussion. - Doug From mentor@alb-net.com Fri Aug 17 21:48:22 2001 From: mentor@alb-net.com (Mentor Cana) Date: Fri, 17 Aug 2001 16:48:22 -0400 (EDT) Subject: [Mailman-Developers] Re: SPAM filtering problem In-Reply-To: <20010817204158.2641E9B13@squall.waterspout.com> Message-ID: On Fri, 17 Aug 2001, at 15:40 -0500, Doug Porter wrote: > Are they really filtering based on `Precedence: bulk' and calling > it spam? I doubt many spammers are polite enough to add that > header. ;P If they are only placing it into a bulk folder though > and not calling it spam that seems like an okay thing to do. :/ I think that the filtering seems to be done based on the fact that recipient e-mail address does not appear in the To: or Cc: field. -- Mentor From barry@zope.com Fri Aug 17 22:12:53 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 17 Aug 2001 17:12:53 -0400 Subject: [Mailman-Developers] SPAM filtering problem References: <4.2.0.58.20010817150301.00a72880@perilpoint.com> Message-ID: <15229.35029.212109.427279@anthem.wooz.org> >>>>> "BS" == Bradford Shaw writes: | (1) removing the Precedence: bulk header | or changing it to something like 'private' or 'registered' As others have pointed out, this is a really bad idea. | (2) to have the To: header addressed to the receiver | instead of the list address Now, /this/ will be possible in Mailman 2.1, at least for regular deliveries. If the site administrator enables it, a Mailman list can be set up to `personalize' regular deliveries. Mailman will let you put some personal information in the header and footers, and (in a few moments :) it will set the To: field to the recipient. Note that this kind of personalized mailing list can have a severe impact on performance. Imagine a list with 100k members, and you enable personalization. Every message you send just got exploded from one message going from Mailman->MTA to 100k. :) -Barry From jra@baylink.com Fri Aug 17 22:41:05 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Fri, 17 Aug 2001 17:41:05 -0400 Subject: [Mailman-Developers] SPAM filtering problem In-Reply-To: <15229.35029.212109.427279@anthem.wooz.org>; from "Barry A. Warsaw" on Fri, Aug 17, 2001 at 05:12:53PM -0400 References: <4.2.0.58.20010817150301.00a72880@perilpoint.com> <15229.35029.212109.427279@anthem.wooz.org> Message-ID: <20010817174105.24889@scfn.thpl.lib.fl.us> On Fri, Aug 17, 2001 at 05:12:53PM -0400, Barry A. Warsaw wrote: > Now, /this/ will be possible in Mailman 2.1, at least for regular > deliveries. If the site administrator enables it, a Mailman list can > be set up to `personalize' regular deliveries. Mailman will let you > put some personal information in the header and footers, and (in a few > moments :) it will set the To: field to the recipient. Is that VERP? Or something similar? VERP looks spiffy, if you have the horsepower and bandwidth... 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 804 5015 "So easy to use, no wonder the Internet is going to hell!" -- me From barry@zope.com Fri Aug 17 23:03:17 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 17 Aug 2001 18:03:17 -0400 Subject: [Mailman-Developers] SPAM filtering problem References: <4.2.0.58.20010817150301.00a72880@perilpoint.com> <15229.35029.212109.427279@anthem.wooz.org> <20010817174105.24889@scfn.thpl.lib.fl.us> Message-ID: <15229.38053.65666.700524@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> On Fri, Aug 17, 2001 at 05:12:53PM -0400, Barry A. Warsaw JRA> wrote: >> Now, /this/ will be possible in Mailman 2.1, at least for >> regular deliveries. If the site administrator enables it, a >> Mailman list can be set up to `personalize' regular deliveries. >> Mailman will let you put some personal information in the >> header and footers, and (in a few moments :) it will set the >> To: field to the recipient. JRA> Is that VERP? Or something similar? It's not technically VERP unless that's short for Very Easy Regular-delivery Personalization :). There's no cooperation from the MTA -- its all done in Mailman. JRA> VERP looks spiffy, if you have the horsepower and JRA> bandwidth... Indeed. There may be opportunities for improving performance w/ some cooperation from the MTA, but I'm not thinking about that for now. Also, right now digests can't be personalized. -Barry From jra@baylink.com Fri Aug 17 23:05:49 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Fri, 17 Aug 2001 18:05:49 -0400 Subject: [Mailman-Developers] SPAM filtering problem In-Reply-To: <15229.38053.65666.700524@anthem.wooz.org>; from "Barry A. Warsaw" on Fri, Aug 17, 2001 at 06:03:17PM -0400 References: <4.2.0.58.20010817150301.00a72880@perilpoint.com> <15229.35029.212109.427279@anthem.wooz.org> <20010817174105.24889@scfn.thpl.lib.fl.us> <15229.38053.65666.700524@anthem.wooz.org> Message-ID: <20010817180549.33689@scfn.thpl.lib.fl.us> On Fri, Aug 17, 2001 at 06:03:17PM -0400, Barry A. Warsaw wrote: > JRA> Is that VERP? Or something similar? > > It's not technically VERP unless that's short for Very Easy > Regular-delivery Personalization :). There's no cooperation from the > MTA -- its all done in Mailman. I don't recall that VERP requires cooperation from the MTA, either, does it? it's just customization of the From_ line to match the message. > JRA> VERP looks spiffy, if you have the horsepower and > JRA> bandwidth... > > Indeed. There may be opportunities for improving performance w/ some > cooperation from the MTA, but I'm not thinking about that for now. > Also, right now digests can't be personalized. Indeed? 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 804 5015 "So easy to use, no wonder the Internet is going to hell!" -- me From barry@zope.com Sat Aug 18 00:07:38 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 17 Aug 2001 19:07:38 -0400 Subject: [Mailman-Developers] Re: Starting mailmanctl References: <15228.17282.453597.281340@localhost.localdomain> Message-ID: <15229.41914.731539.489706@anthem.wooz.org> >>>>> "OW" == Ousmane Wilane writes: OW> IMHO, we'd better let `chkconfig' manage /etc/rc.d dir hier Daniel Buchmann mentioned chkconfig in private email too. I must admit that I've never even heard of chkconfig until now. ;) I see no reason why we shouldn't support it for systems that use it, so I'm going to move misc/S98mailman.in to misc/mailman.in and update the installation instructions accordingly. I'd love it if you folks could proofread the info once I check it all in. >>>>> "JCL" == J C Lawrence writes: JCL> This is not true for Debian, and other .deb based Linux JCL> distributions. Its also not true for Solaris, HP-UX, AIX, JCL> and several other commercial *ixes. Contributions to support these other *nixes are, of course, welcome! Thanks, -Barry From barry@zope.com Sat Aug 18 00:10:43 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 17 Aug 2001 19:10:43 -0400 Subject: [Mailman-Developers] mailman 2.1a2 -- mailmanctl -- memory usage References: <61109.62.252.176.103.998002382.squirrel@webmail.atackscomputers.co.uk> Message-ID: <15229.42099.308908.716241@anthem.wooz.org> >>>>> "SA" == Simon Atack writes: SA> The problem occurs because running mailmanctl start once for SA> each domain, runs 7 python ./mailmanctl start that use around SA> 3.4Mb each. after several the machine started to use vast SA> quantities of ram so i didnt upgrade the rest of the test SA> lists. Is there any way of reducing the memory foot print of SA> each of these runners, or maybe just run 1 instead of 7? SA> Is it possible to somehow go back to doing it the old way via SA> a cron job? as the machine didnt have a problem running these I see two possible solutions: 1) Bite the bullet and support true virtual domains, so you'd only need one installation per site, and one invocation of mailmanctl to service all your domains. 2) Provide a low-cost fallback for a cron-invoked qrunner. Unless someone comes out of the woodwork and funds #1 within the next couple of weeks , I don't see it happening for MM2.1. #2 should be doable, so I'll look into that as MM2.1 moves forward. -Barry From scott-brown@home.com Sat Aug 18 00:46:23 2001 From: scott-brown@home.com (Scott Brown) Date: Fri, 17 Aug 2001 19:46:23 -0400 Subject: [Mailman-Developers] mailman 2.1a2 -- mailmanctl -- memory usage In-Reply-To: <15229.42099.308908.716241@anthem.wooz.org> Message-ID: <001601c12776$d30f3d20$0401a8c0@ibmpeers> > > I see two possible solutions: > > 1) Bite the bullet and support true virtual domains, so you'd only > need one installation per site, and one invocation of mailmanctl to > service all your domains. > > 2) Provide a low-cost fallback for a cron-invoked qrunner. > > Unless someone comes out of the woodwork and funds #1 within the next > couple of weeks , I don't see it happening for MM2.1. #2 should > be doable, so I'll look into that as MM2.1 moves forward. > I've played with it in a vhost environment (one install for many [...well, 3 on my test box...] sites) I have mailman 2.1a2 installed once on the box, and the vhosts reference that install via proxy'd requests to localhost. The only thing that I've run across that causes me headaches is the fact that (on the drop I've been playing with) new lists are created with the system name, not the name of the vhost which is requesting it. On the lighter size, I've also noticed under 2.0.6 (cant say under 2.1.a2) an occasional place (list of lists is a prime example) that references 'localhost' because I'm accessing the /mailman/ pages via a proxy to get arround SUEXEC limitations. Perhaps #1 could be done easily by examining where new data is created and a domain name is required, and using the vhost domain from the requesting url, rather than the system name (watch for proxy'd requests though :) Command line proggies would then need to be able to specify a vhost on the command line with a new switch. A pro like you should be able to knock that off in a couple days, no? :)) From barry@zope.com Sat Aug 18 01:00:19 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 17 Aug 2001 20:00:19 -0400 Subject: [Mailman-Developers] SPAM filtering problem References: <4.2.0.58.20010817150301.00a72880@perilpoint.com> <15229.35029.212109.427279@anthem.wooz.org> <20010817174105.24889@scfn.thpl.lib.fl.us> <15229.38053.65666.700524@anthem.wooz.org> <20010817180549.33689@scfn.thpl.lib.fl.us> Message-ID: <15229.45075.366556.484905@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> I don't recall that VERP requires cooperation from the MTA, JRA> either, does it? it's just customization of the From_ line JRA> to match the message. VERP according to DJB[*] means varying the envelope sender so that bounces will be guaranteed to include the intended recipient's address unambiguously. You need cooperation from the MTA so that it will accept wildcard recipients. Most do, but you'd have to configure it in and have something in Mailman to receive and decipher the bounces. I may still add this side of things to MM2.1. >> Indeed. There may be opportunities for improving performance >> w/ some cooperation from the MTA, but I'm not thinking about >> that for now. Also, right now digests can't be personalized. JRA> Indeed? Yeah, just because the code in ToDigest.py is not structured to support it easily. :( -Barry [*] http://cr.yp.to/proto/verp.txt From barry@zope.com Sat Aug 18 01:11:16 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 17 Aug 2001 20:11:16 -0400 Subject: [Mailman-Developers] mailman 2.1a2 -- mailmanctl -- memory usage References: <15229.42099.308908.716241@anthem.wooz.org> <001601c12776$d30f3d20$0401a8c0@ibmpeers> Message-ID: <15229.45732.786649.840142@anthem.wooz.org> >>>>> "SB" == Scott Brown writes: SB> The only thing that I've run across that causes me headaches SB> is the fact that (on the drop I've been playing with) new SB> lists are created with the system name, not the name of the SB> vhost which is requesting it. Are you using bin/newlist or thru-the-web list creation? bin/newlist supports a syntax for listnames that specify the vhost to use, and thru-the-web should decipher the vhost specified in the url (but that may be buggy). SB> Perhaps #1 could be done easily by examining where new data is SB> created and a domain name is required, and using the vhost SB> domain from the requesting url, rather than the system name SB> (watch for proxy'd requests though :) Command line proggies SB> would then need to be able to specify a vhost on the command SB> line with a new switch. SB> A pro like you should be able to knock that off in a couple SB> days, no? I think figuring out the right vhost to use is tractable, but there are a few issues that, while not terribly difficult, will require a lot of tedious code hackery and testing: - List databases are all stored in the same "namespace" (i.e. directory) in $prefix/lists. The vhost would have to be encoded in the path, either in a subdirectory, or by encoding it in the list's directory name (which is a lot of work because then MailList.internal_name() doesn't point to the directory). - To do this The Right Way, you really want to allow the site admin to set up different defaults for each vhost. You're probably talking about a separate mm_cfg.py-style file for each vhost, and architecting that and updating all the code isn't a trivial amount of work. - DEFAULT_HOST_NAME vs. DEFAULT_URL. Each vhost is identified by both variables (e.g. mail.python.org and list@python.org). So you need to create a mapping of vhost to those two variables, and use the right one in the right context. Looking ahead at the time available to finish up MM2.1, I just don't see it as being feasible. -Barry From scott-brown@home.com Sat Aug 18 01:48:34 2001 From: scott-brown@home.com (Scott Brown) Date: Fri, 17 Aug 2001 20:48:34 -0400 Subject: [Mailman-Developers] mailman 2.1a2 -- mailmanctl -- memory usage In-Reply-To: <15229.45732.786649.840142@anthem.wooz.org> Message-ID: <001901c1277f$8291af00$0401a8c0@ibmpeers> > >>>>> "SB" == Scott Brown writes: > > SB> The only thing that I've run across that causes me headaches > SB> is the fact that (on the drop I've been playing with) new > SB> lists are created with the system name, not the name of the > SB> vhost which is requesting it. > > Are you using bin/newlist or thru-the-web list creation? bin/newlist > supports a syntax for listnames that specify the vhost to use, and > thru-the-web should decipher the vhost specified in the url (but that > may be buggy). thru-da-web :) I sent you a mention of this bug a week or so ago (you might have been on vacation then :) > SB> Perhaps #1 could be done easily by examining where new data is > SB> created and a domain name is required, and using the vhost > SB> domain from the requesting url, rather than the system name > SB> (watch for proxy'd requests though :) Command line proggies > SB> would then need to be able to specify a vhost on the command > SB> line with a new switch. > > SB> A pro like you should be able to knock that off in a couple > SB> days, no? > > I think figuring out the right vhost to use is tractable, but there > are a few issues that, while not terribly difficult, will require a > lot of tedious code hackery and testing: > > - List databases are all stored in the same "namespace" > (i.e. directory) in $prefix/lists. The vhost would have to be > encoded in the path, either in a subdirectory, or by encoding it in > the list's directory name (which is a lot of work because then > MailList.internal_name() doesn't point to the directory). In a perfect world, yes, that would be the best (I mentioned this on the wikki)... but if you were to look at sliding vhost support in gradually (which is a reasonable expectation considering how much could be upset in an all-or-nothing change set) then I dont see a problem with the unique-list-names-per-server approach at this time (I've got that same limitation on my prod server right now with the way things are setup... no-one seems to care about that limitation... and I'm sure that knowing that v2.2 (or v3.0) would have this restriction removed would placeate most people who might get their shorts in a knot). I dont think that the people who have been performing full installs per vhost would be upset by a gradual insertion, since they're treating each host uniquely anyways. > - To do this The Right Way, you really want to allow the site admin to > set up different defaults for each vhost. You're probably talking > about a separate mm_cfg.py-style file for each vhost, and > architecting that and updating all the code isn't a trivial amount > of work. Why not just accept the system defaults, except where it's vhost relevant? Granted, even my production server has a limited userbase, but I know I'd set up all hosts the same from the start (though others might not). I guess it falls back to the business model. Of course, if you're REALLY wanting to make an inroads into a vhosting environment, then you'd also need to be able to configure the max lists allowed per domain. Me - personally - "IDontCare"(tm) if someone has 1 or 100. > - DEFAULT_HOST_NAME vs. DEFAULT_URL. Each vhost is identified by both > variables (e.g. mail.python.org and list@python.org). So you need > to create a mapping of vhost to those two variables, and use the > right one in the right context. True enough - but both are (something)python.org. Right now, unless you override things, you get default_host as 'hostname' and default_url as http://'hostname'/mailman/ ... spitting the vhost name into either one is a heck of a lot closer than 'hostname'. And it would only be necessary on creation of new records, no? Once the data's there, it could be modified by the user, so current processes would (to my mind) still hold up. > Looking ahead at the time available to finish up MM2.1, I just don't > see it as being feasible. Heh... worth a shot :) MM2.1 is already including a number of goodies that will be useful... and I'm probably as anxious as you to get a release version out... From stdarg@yahoo.com Sun Aug 19 09:04:08 2001 From: stdarg@yahoo.com (stdarg) Date: Sun, 19 Aug 2001 01:04:08 -0700 (PDT) Subject: [Mailman-Developers] feature suggestion: attachment mirroring Message-ID: <20010819080408.87676.qmail@web13101.mail.yahoo.com> I think a nice feature would be for mailman to mirror large attachments (configurable size) on a website, and then replace the attachment with a link to the mirror, instead of sending it to everybody or rejecting the message. Example: stdarg@yahoo.com sends a small message (patch description) and a large attachment (actual patch) to eggdev@eggheads.org mailman sees that the attachment is over 20kb (or whatever), so it saves the attachment locally in a public html directory. mailman sends the mail out to the list, but replaces the large attachment with a link like http://archive.eggheads.org/attachments/998207905/my_attachment_name.patch thanks :) __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From che@debian.org Mon Aug 20 04:57:53 2001 From: che@debian.org (Ben Gertzfield) Date: Mon, 20 Aug 2001 12:57:53 +0900 Subject: [Mailman-Developers] Patching qrunner to never send duplicates w/ same Message-ID Message-ID: <87pu9rs7r2.fsf@nausicaa.interq.or.jp> I'm interested in killing two birds with one stone; I'm presently moving a company's massive (> 1200 line) aliases file that has grown unmaintainable to Mailman, so that the sysadmins can let the list admins maintain their own subscriber lists. The one problem is that people at the company are used to Cc:ing multiple aliases and having only *one* copy of the email reach the final recipient, even if the recipient is a member of multiple aliases in the Cc: list. Sendmail would handle this internally with the old way of using one massive aliases file, because it would expand all aliases and only send one mail to each final address. This has been discussed before on mailman-users at http://mail.python.org/pipermail/mailman-users/2000-September/006880.html -- the answer there was of course "force the users to use a different MUA". Yes, I know the proper solution is to have the MUA ignore duplicate mails with the same Message-ID, but it's impossible to get a company to all switch to mailers that support this. I would like to work on a different solution; I think it might be possible to modify the Mailman queue runner to never send out multiple messages with the same Message-ID to the same recipient. Looking through the source in Mailman/Queue, I see that each mail's destination is put into its own marshalled .db file in /var/lib/mailman/qfiles, so we will have to keep state to avoid sending duplicates. The way Gnus (the best mail reader on the planet, natch) handles this is by keeping a cache of the past X Message-IDs (1000 by default, obviously tuneable); we could pretty easily keep a list of Message-IDs and recipient pairs, and do one of the following if a message is about to be sent out to a recipient that has already received an email with that Message-ID: 1) Do nothing. (to keep current behavior) 2) Add a warning header to let the users filter on their own 3) Don't send out the message. This could be configurable per-user, and I think it'd be a great improvement over the current state of things. Would a patch for this be accepted? At which point of the queue runner do we want to deal with this? Mailman.Queue.OutgoingRunner might be the right place, but I'm not sure. Ben -- Brought to you by the letters L and J and the number 12. "A calpac is a large cap." Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From barry@zope.com Mon Aug 20 15:43:36 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 20 Aug 2001 10:43:36 -0400 Subject: [Mailman-Developers] Patching qrunner to never send duplicates w/ same Message-ID References: <87pu9rs7r2.fsf@nausicaa.interq.or.jp> Message-ID: <15233.8728.923029.568314@anthem.wooz.org> >>>>> "BG" == Ben Gertzfield writes: BG> I would like to work on a different solution; I think it might BG> be possible to modify the Mailman queue runner to never send BG> out multiple messages with the same Message-ID to the same BG> recipient. Looking through the source in Mailman/Queue, I see BG> that each mail's destination is put into its own marshalled BG> .db file in /var/lib/mailman/qfiles, so we will have to keep BG> state to avoid sending duplicates. BG> The way Gnus (the best mail reader on the planet, natch) BG> handles this is by keeping a cache of the past X Message-IDs BG> (1000 by default, obviously tuneable); we could pretty easily BG> keep a list of Message-IDs and recipient pairs, and do one of BG> the following if a message is about to be sent out to a BG> recipient that has already received an email with that BG> Message-ID: | 1) Do nothing. (to keep current behavior) | 2) Add a warning header to let the users filter on their own | 3) Don't send out the message. BG> This could be configurable per-user, and I think it'd be a BG> great improvement over the current state of things. BG> Would a patch for this be accepted? At which point of the BG> queue runner do we want to deal with this? BG> Mailman.Queue.OutgoingRunner might be the right place, but I'm BG> not sure. I would try to implement this is a handler module (see GLOBAL_PIPELINE in Defaults.py) to be run just after CalcRecips.py. To avoid locking issues, keep the table as an in memory dictionary; you'll lose it when you restart the qrunner, but that's probably better than having to lock a list-external resource (creating a potential bottleneck). As a bonus, you might also want to cull recipients if you notice their address is explicitly listed in the To: or Cc: headers, on the assumption that they will probably see this message twice. Again, that should be user configurable too. The actual implementation of this feature shouldn't be too hard -- it's the GUI aspects that'll take some time. You'll have to modify options.html and options.py to expose the user controls, and you'll have to add a user option flag in Defaults.py.in. I might accept such a patch for MM2.1 if it gets submitted fairly soon and cleanly applies to cvs. I'm hoping to get alpha3 out today or tomorrow, and this will likely be the last alpha (meaning feature freeze with the following beta1 release). -Barry From jra@baylink.com Mon Aug 20 15:59:45 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 20 Aug 2001 10:59:45 -0400 Subject: [Mailman-Developers] Patching qrunner to never send duplicates w/ same Message-ID In-Reply-To: <15233.8728.923029.568314@anthem.wooz.org>; from "Barry A. Warsaw" on Mon, Aug 20, 2001 at 10:43:36AM -0400 References: <87pu9rs7r2.fsf@nausicaa.interq.or.jp> <15233.8728.923029.568314@anthem.wooz.org> Message-ID: <20010820105945.10636@scfn.thpl.lib.fl.us> On Mon, Aug 20, 2001 at 10:43:36AM -0400, Barry A. Warsaw wrote: > As a bonus, you might also want to cull recipients if you notice their > address is explicitly listed in the To: or Cc: headers, on the > assumption that they will probably see this message twice. Again, > that should be user configurable too. If you're going to do this, note that it's the *list* message that should make it to the user, not the private copy... and I don't think you can accomplish this. Knowing that the list actually *saw* the message can be important information... 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 804 5015 "So easy to use, no wonder the Internet is going to hell!" -- me From barry@zope.com Mon Aug 20 16:17:33 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 20 Aug 2001 11:17:33 -0400 Subject: [Mailman-Developers] Patching qrunner to never send duplicates w/ same Message-ID References: <87pu9rs7r2.fsf@nausicaa.interq.or.jp> <15233.8728.923029.568314@anthem.wooz.org> <20010820105945.10636@scfn.thpl.lib.fl.us> Message-ID: <15233.10765.367781.639149@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> If you're going to do this, note that it's the *list* message JRA> that should make it to the user, not the private copy... and JRA> I don't think you can accomplish this. Knowing that the list JRA> actually *saw* the message can be important information... You're right that there's no way Mailman can suppress the private copy since it never even sees that copy, but I /was/ suggesting that Mailman could suppress the list copy -- but only if the user has selected an option to do so. -Barry From jra@baylink.com Mon Aug 20 17:14:17 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 20 Aug 2001 12:14:17 -0400 Subject: [Mailman-Developers] Patching qrunner to never send duplicates w/ same Message-ID In-Reply-To: <15233.10765.367781.639149@anthem.wooz.org>; from "Barry A. Warsaw" on Mon, Aug 20, 2001 at 11:17:33AM -0400 References: <87pu9rs7r2.fsf@nausicaa.interq.or.jp> <15233.8728.923029.568314@anthem.wooz.org> <20010820105945.10636@scfn.thpl.lib.fl.us> <15233.10765.367781.639149@anthem.wooz.org> Message-ID: <20010820121417.03731@scfn.thpl.lib.fl.us> On Mon, Aug 20, 2001 at 11:17:33AM -0400, Barry A. Warsaw wrote: > >>>>> "JRA" == Jay R Ashworth writes: > > JRA> If you're going to do this, note that it's the *list* message > JRA> that should make it to the user, not the private copy... and > JRA> I don't think you can accomplish this. Knowing that the list > JRA> actually *saw* the message can be important information... > > You're right that there's no way Mailman can suppress the private copy > since it never even sees that copy, but I /was/ suggesting that > Mailman could suppress the list copy -- but only if the user has > selected an option to do so. The user's option, certainly, but *I* want to know that copy made the list. I always leave meetoo set, too. I'd like to see mailers that can, like Mutt, reply to the list wihtout *having* to carbon the other user, since that's where most dupes -- like yourn :-) -- come from. 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 804 5015 "So easy to use, no wonder the Internet is going to hell!" -- me From barry@zope.com Mon Aug 20 17:30:36 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 20 Aug 2001 12:30:36 -0400 Subject: [Mailman-Developers] Patching qrunner to never send duplicates w/ same Message-ID References: <87pu9rs7r2.fsf@nausicaa.interq.or.jp> <15233.8728.923029.568314@anthem.wooz.org> <20010820105945.10636@scfn.thpl.lib.fl.us> <15233.10765.367781.639149@anthem.wooz.org> <20010820121417.03731@scfn.thpl.lib.fl.us> Message-ID: <15233.15148.535006.951339@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> The user's option, certainly, but *I* want to know that copy JRA> made the list. I always leave meetoo set, too. I'd like to JRA> see mailers that can, like Mutt, reply to the list wihtout JRA> *having* to carbon the other user, since that's where most JRA> dupes -- like yourn :-) -- come from. It's a sticky issue. How does my MUA (XEmacs/VM BTW) know that jra@baylink.com is actually on the mailman-developers@python.org list? Note that /I'm/ pretty sure you are, so I just trimmed the headers. ;) What rules does Mutt use to trim the recipients? -Barry From jra@baylink.com Mon Aug 20 18:03:55 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 20 Aug 2001 13:03:55 -0400 Subject: [Mailman-Developers] Patching qrunner to never send duplicates w/ same Message-ID In-Reply-To: <15233.15148.535006.951339@anthem.wooz.org>; from "Barry A. Warsaw" on Mon, Aug 20, 2001 at 12:30:36PM -0400 References: <87pu9rs7r2.fsf@nausicaa.interq.or.jp> <15233.8728.923029.568314@anthem.wooz.org> <20010820105945.10636@scfn.thpl.lib.fl.us> <15233.10765.367781.639149@anthem.wooz.org> <20010820121417.03731@scfn.thpl.lib.fl.us> <15233.15148.535006.951339@anthem.wooz.org> Message-ID: <20010820130355.11877@scfn.thpl.lib.fl.us> On Mon, Aug 20, 2001 at 12:30:36PM -0400, Barry A. Warsaw wrote: > >>>>> "JRA" == Jay R Ashworth writes: > JRA> The user's option, certainly, but *I* want to know that copy > JRA> made the list. I always leave meetoo set, too. I'd like to > JRA> see mailers that can, like Mutt, reply to the list wihtout > JRA> *having* to carbon the other user, since that's where most > JRA> dupes -- like yourn :-) -- come from. > > It's a sticky issue. How does my MUA (XEmacs/VM BTW) know that > jra@baylink.com is actually on the mailman-developers@python.org list? > > Note that /I'm/ pretty sure you are, so I just trimmed the headers. ;) > What rules does Mutt use to trim the recipients? You *tell* mutt which To: addresses are lists, and then you can use the 'L' key to reply to the list, or the traditional 'r' key to reply only to the sender. It *could* look for Precedence: list, I suspect, but I don't think anyone ever cared enough to put it in there. Or maybe me didn't like the idea. 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 804 5015 "So easy to use, no wonder the Internet is going to hell!" -- me From mrbill@mrbill.net Mon Aug 20 18:09:38 2001 From: mrbill@mrbill.net (Bill Bradford) Date: Mon, 20 Aug 2001 12:09:38 -0500 Subject: [Mailman-Developers] 2.1 eta? Message-ID: <20010820120938.T26783@mrbill.net> Any eta/timeframe for a 2.1 final release? Bill -- Bill Bradford mrbill@mrbill.net Austin, TX From trey@anvils.org Mon Aug 20 18:31:23 2001 From: trey@anvils.org (Trey Valenta) Date: Mon, 20 Aug 2001 10:31:23 -0700 Subject: [Mailman-Developers] feature suggestion: attachment mirroring In-Reply-To: <20010819080408.87676.qmail@web13101.mail.yahoo.com>; from stdarg@yahoo.com on Sun, Aug 19, 2001 at 01:04:08AM -0700 References: <20010819080408.87676.qmail@web13101.mail.yahoo.com> Message-ID: <20010820103123.A18443@anvils.org> > I think a nice feature would be for mailman to mirror > large attachments (configurable size) on a website, > and then replace the attachment with a link to the > mirror, instead of sending it to everybody or > rejecting the message. It seems that this would be something that could be part of a larger project, essentially involving MIME support. I wouldn't want all attachments stripped but would like to be able to strip them based on type; e.g. images or sound files are stripped from the message before re-sending it, regular text is kept. Perhaps if this could be done somewhat modularly, it would lend itself to other uses, like PGP support... i.e. images are stripped, text messages are left alone, pgp encrypted messages (sent as mime attachments) are decrypted and re-encrypted with the list manager's key. Just my $0.00002 worth. -- trey valenta trey@anvils.org seattle (maybe a) random quote--v People love high ideals, but they got to be about 33-percent plausible. -- The Best of Will Rogers From jarrell@vt.edu Mon Aug 20 18:59:00 2001 From: jarrell@vt.edu (Ron Jarrell) Date: Mon, 20 Aug 2001 13:59:00 -0400 Subject: [Mailman-Developers] 2.1 eta? In-Reply-To: <20010820120938.T26783@mrbill.net> Message-ID: <5.1.0.14.2.20010820135843.045cbc40@lennier.cc.vt.edu> At 12:09 PM 8/20/01 -0500, Bill Bradford wrote: >Any eta/timeframe for a 2.1 final release? First I think we need a 2.1 beta... From barry@zope.com Mon Aug 20 19:35:28 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 20 Aug 2001 14:35:28 -0400 Subject: [Mailman-Developers] Patching qrunner to never send duplicates w/ same Message-ID References: <87pu9rs7r2.fsf@nausicaa.interq.or.jp> <15233.8728.923029.568314@anthem.wooz.org> <20010820105945.10636@scfn.thpl.lib.fl.us> <15233.10765.367781.639149@anthem.wooz.org> <20010820121417.03731@scfn.thpl.lib.fl.us> <15233.15148.535006.951339@anthem.wooz.org> <20010820130355.11877@scfn.thpl.lib.fl.us> Message-ID: <15233.22640.481533.421976@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> You *tell* mutt which To: addresses are lists, and then you JRA> can use the 'L' key to reply to the list, or the traditional JRA> 'r' key to reply only to the sender. Yes, but what happens when a non-member posts to a list? They won't see your response. -Barry From marc_news@valinux.com Mon Aug 20 19:48:12 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Mon, 20 Aug 2001 11:48:12 -0700 Subject: [Mailman-Developers] Patching qrunner to never send duplicates w/ same Message-ID In-Reply-To: <15233.22640.481533.421976@anthem.wooz.org>; from barry@zope.com on Mon, Aug 20, 2001 at 02:35:28PM -0400 References: <87pu9rs7r2.fsf@nausicaa.interq.or.jp> <15233.8728.923029.568314@anthem.wooz.org> <20010820105945.10636@scfn.thpl.lib.fl.us> <15233.10765.367781.639149@anthem.wooz.org> <20010820121417.03731@scfn.thpl.lib.fl.us> <15233.15148.535006.951339@anthem.wooz.org> <20010820130355.11877@scfn.thpl.lib.fl.us> <15233.22640.481533.421976@anthem.wooz.org> Message-ID: <20010820114812.D22426@magic.merlins.org> On Mon, Aug 20, 2001 at 02:35:28PM -0400, Barry A. Warsaw wrote: > > >>>>> "JRA" == Jay R Ashworth writes: > > JRA> You *tell* mutt which To: addresses are lists, and then you > JRA> can use the 'L' key to reply to the list, or the traditional > JRA> 'r' key to reply only to the sender. > > Yes, but what happens when a non-member posts to a list? They won't > see your response. Correct, but 1) That's too bad :-) 2) Many lists don't let non subscribers post anymore. That's actually slowly becoming the norm 3) If you can post to a list you're not a member of, you are expected to add a line at the top asking to be Cced because you don't receive the list. While we are on this topic, I would really love for a way for mailman to optionally parse the Cc and To lines and not send a post to a subscribed address if that address was already in the headers. The idea is that I'm stuck with a list that has the evil reply-to munging, and the subscribers refuse to have the reply-to munging removed because they can't bear the fact of receiving two copies of posts when they are Cced in an answer (no, they can't use procmail to weed duplicate msg-ids) As evil as it is, reply-to munging does kind of aleviate that problem (i.e. reply to all usually only goes to To: Cc: and Reply-To:, not to From:) I'm not sure how hard it would be for mailman to do that. Marc -- 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 Mon Aug 20 20:07:10 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 20 Aug 2001 15:07:10 -0400 Subject: [Mailman-Developers] Patching qrunner to never send duplicates w/ same Message-ID In-Reply-To: <20010820114812.D22426@magic.merlins.org>; from Marc MERLIN on Mon, Aug 20, 2001 at 11:48:12AM -0700 References: <87pu9rs7r2.fsf@nausicaa.interq.or.jp> <15233.8728.923029.568314@anthem.wooz.org> <20010820105945.10636@scfn.thpl.lib.fl.us> <15233.10765.367781.639149@anthem.wooz.org> <20010820121417.03731@scfn.thpl.lib.fl.us> <15233.15148.535006.951339@anthem.wooz.org> <20010820130355.11877@scfn.thpl.lib.fl.us> <15233.22640.481533.421976@anthem.wooz.org> <20010820114812.D22426@magic.merlins.org> Message-ID: <20010820150710.54092@scfn.thpl.lib.fl.us> On Mon, Aug 20, 2001 at 11:48:12AM -0700, Marc MERLIN wrote: > On Mon, Aug 20, 2001 at 02:35:28PM -0400, Barry A. Warsaw wrote: > > >>>>> "JRA" == Jay R Ashworth writes: > > JRA> You *tell* mutt which To: addresses are lists, and then you > > JRA> can use the 'L' key to reply to the list, or the traditional > > JRA> 'r' key to reply only to the sender. > > > > Yes, but what happens when a non-member posts to a list? They won't > > see your response. > > Correct, but > 1) That's too bad :-) Concur. :-) > 2) Many lists don't let non subscribers post anymore. That's actually slowly > becoming the norm > 3) If you can post to a list you're not a member of, you are expected to add > a line at the top asking to be Cced because you don't receive the list. Which will likely be ignored, if not scoffed at; see 1). ;-) > While we are on this topic, I would really love for a way for mailman to > optionally parse the Cc and To lines and not send a post to a subscribed > address if that address was already in the headers. Nope; not unless it's configurable. That's actually what we were just talking about, and -- at least personally -- *I* want to *know* that the message was visible to the rest of the list, whether I sent it, or whether it was carboned to me (your suggestion would break *both* of those). > The idea is that I'm stuck with a list that has the evil reply-to munging, > and the subscribers refuse to have the reply-to munging removed because they > can't bear the fact of receiving two copies of posts when they are Cced in > an answer (no, they can't use procmail to weed duplicate msg-ids) > As evil as it is, reply-to munging does kind of aleviate that problem (i.e. > reply to all usually only goes to To: Cc: and Reply-To:, not to From:) You know it's evil, so I don't have to point you to the Rosenthal Memorandum. > I'm not sure how hard it would be for mailman to do that. If they insist on continued munging, allow them to Feel Their Own Pain. They're entitled. 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 804 5015 "So easy to use, no wonder the Internet is going to hell!" -- me From barry@zope.com Mon Aug 20 20:39:50 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 20 Aug 2001 15:39:50 -0400 Subject: [Mailman-Developers] feature suggestion: attachment mirroring References: <20010819080408.87676.qmail@web13101.mail.yahoo.com> <20010820103123.A18443@anvils.org> Message-ID: <15233.26502.2392.434530@anthem.wooz.org> >>>>> "TV" == Trey Valenta writes: >> I think a nice feature would be for mailman to mirror large >> attachments (configurable size) on a website, and then replace >> the attachment with a link to the mirror, instead of sending it >> to everybody or rejecting the message. TV> It seems that this would be something that could be part of a TV> larger project, essentially involving MIME support. I wouldn't TV> want all attachments stripped but would like to be able to TV> strip them based on type; e.g. images or sound files are TV> stripped from the message before re-sending it, regular text TV> is kept. I completely agree, but I decided that it will have to wait until after MM2.1. -Barry From barry@zope.com Mon Aug 20 20:52:37 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 20 Aug 2001 15:52:37 -0400 Subject: [Mailman-Developers] 2.1 eta? References: <20010820120938.T26783@mrbill.net> <5.1.0.14.2.20010820135843.045cbc40@lennier.cc.vt.edu> Message-ID: <15233.27269.843024.779688@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: >> Any eta/timeframe for a 2.1 final release? RJ> First I think we need a 2.1 beta... Right! BTW, I've been nominated as Python 2.2 release manager so with Py2.2a2 coming out Wednesday, that is taking precedence. I had hoped to get MM2.1a3 out last weekend but it didn't happen, so my plan is now to get MM2.1a3 out this week, probably some time after Wednesday. MM2.1a3 will be the last alpha. That means the following release will be MM2.1beta1 and that will mark feature freeze. A very rough schedule is as follows: 24-Aug MM2.1 a3 28-Sep MM2.1 b1 26-Oct MM2.1 b2 23-Nov MM2.1 b3 (if necessary, otherwise MM2.1 rc1) 21-Dec MM2.1 rc1 (if necessary, otherwise MM2.1 final) 28-Dec MM2.1 final Too many other things may change this schedule so I won't commit to it, but it's what I'm shooting for. Might be earlier, might be later. -Barry From jarrell@vt.edu Mon Aug 20 21:05:11 2001 From: jarrell@vt.edu (Ron Jarrell) Date: Mon, 20 Aug 2001 16:05:11 -0400 Subject: [Mailman-Developers] current snapshot install prob. Message-ID: <5.1.0.14.2.20010820160204.038b8980@lennier.cc.vt.edu> Barry, I just loaded the current snapshot, did the config, make, and am now trying to install, and the makefile is trying to install addlang, which isn't there... It just got retired, didn't it? Looks like bin/Makefile.in didn't catch up with that idea. From barry@zope.com Mon Aug 20 21:08:49 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 20 Aug 2001 16:08:49 -0400 Subject: [Mailman-Developers] current snapshot install prob. References: <5.1.0.14.2.20010820160204.038b8980@lennier.cc.vt.edu> Message-ID: <15233.28241.468176.711687@anthem.wooz.org> Thanks, fixed! From Dale Newfield Mon Aug 20 21:22:40 2001 From: Dale Newfield (Dale Newfield) Date: Mon, 20 Aug 2001 16:22:40 -0400 (EDT) Subject: [Mailman-Developers] 2.1 eta? In-Reply-To: <15233.27269.843024.779688@anthem.wooz.org> Message-ID: On Mon, 20 Aug 2001, Barry A. Warsaw wrote: > 24-Aug MM2.1 a3 > 28-Sep MM2.1 b1 > 26-Oct MM2.1 b2 > 23-Nov MM2.1 b3 (if necessary, otherwise MM2.1 rc1) > 21-Dec MM2.1 rc1 (if necessary, otherwise MM2.1 final) > 28-Dec MM2.1 final Ahh. I didn't realize the time-scale involved. I'm setting up a new machine to run a handful of domains, and have been delaying the completion of various bits until MM2.1. Clearly that's not a good idea. MM won't be incredibly taxed by this installation--a handful of small lists and one fairly large (<5000 subscribers) announcement-only list. How stupid do you think it would be to use a3 on this site, and then upgrade as bits become available? How easy would it be to do that--is it possible to simply check stuff directly out of the CVS tree, so that I'll be able simply "cvs update" to merge in updates? Would it be a bad idea to merge in updates on a live installation? -Dale From mentor@alb-net.com Mon Aug 20 21:33:41 2001 From: mentor@alb-net.com (Mentor Cana) Date: Mon, 20 Aug 2001 16:33:41 -0400 (EDT) Subject: [Mailman-Developers] 2.1 eta? In-Reply-To: Message-ID: On Mon, 20 Aug 2001, at 16:22 -0400, Dale Newfield wrote: > Ahh. I didn't realize the time-scale involved. I'm setting up a new > machine to run a handful of domains, and have been delaying the completion > of various bits until MM2.1. Clearly that's not a good idea. > > MM won't be incredibly taxed by this installation--a handful of small > lists and one fairly large (<5000 subscribers) announcement-only list. > How stupid do you think it would be to use a3 on this site, and then > upgrade as bits become available? How easy would it be to do that--is it > possible to simply check stuff directly out of the CVS tree, so that I'll > be able simply "cvs update" to merge in updates? Would it be a bad idea > to merge in updates on a live installation? I've been holding on upgrading the production copy until at least the first Beta. The current alpha CVS snapshot seems to be fairly stable. I the stability of the 2.1 betas can be judged by the stability of 2.0 betas, I'll be upgrading to the first 2.1 beta from my 2.0.6. Obviously, after some testing on the most current 2.1 beta (when available) snapshot. -- Mentor From ricardo@rixhq.nu Mon Aug 20 21:41:31 2001 From: ricardo@rixhq.nu (Ricardo F. Kustner) Date: Mon, 20 Aug 2001 22:41:31 +0200 Subject: [Mailman-Developers] 2.1 eta? In-Reply-To: <15233.27269.843024.779688@anthem.wooz.org> References: <20010820120938.T26783@mrbill.net> <5.1.0.14.2.20010820135843.045cbc40@lennier.cc.vt.edu> <15233.27269.843024.779688@anthem.wooz.org> Message-ID: <20010820224131.714fc0d3.ricardo@rixhq.nu> On Mon, 20 Aug 2001 15:52:37 -0400 barry@zope.com (Barry A. Warsaw) wrote: > >>>>> "RJ" == Ron Jarrell writes: > >> Any eta/timeframe for a 2.1 final release? > RJ> First I think we need a 2.1 beta... > BTW, I've been nominated as Python 2.2 release manager so with Py2.2a2 > coming out Wednesday, that is taking precedence. > 24-Aug MM2.1 a3 > 28-Sep MM2.1 b1 ah nice... you can count on me to start debugging it on a production environment starting form MM2.1 b1 :-) Regards, Ricardo. -- "The above message has been blocked because the content was deemed to be unsuitable." -- IMAdmin@*****.co.uk From marc_news@valinux.com Mon Aug 20 22:27:53 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Mon, 20 Aug 2001 14:27:53 -0700 Subject: [Mailman-Developers] Patching qrunner to never send duplicates w/ same Message-ID In-Reply-To: <20010820150710.54092@scfn.thpl.lib.fl.us>; from jra@baylink.com on Mon, Aug 20, 2001 at 03:07:10PM -0400 References: <87pu9rs7r2.fsf@nausicaa.interq.or.jp> <15233.8728.923029.568314@anthem.wooz.org> <20010820105945.10636@scfn.thpl.lib.fl.us> <15233.10765.367781.639149@anthem.wooz.org> <20010820121417.03731@scfn.thpl.lib.fl.us> <15233.15148.535006.951339@anthem.wooz.org> <20010820130355.11877@scfn.thpl.lib.fl.us> <15233.22640.481533.421976@anthem.wooz.org> <20010820114812.D22426@magic.merlins.org> <20010820150710.54092@scfn.thpl.lib.fl.us> Message-ID: <20010820142753.F22426@magic.merlins.org> On Mon, Aug 20, 2001 at 03:07:10PM -0400, Jay R. Ashworth wrote: > > While we are on this topic, I would really love for a way for mailman to > > optionally parse the Cc and To lines and not send a post to a subscribed ^^^^^^^^^^ > > address if that address was already in the headers. > > Nope; not unless it's configurable. That's actually what we were just I said "optionally". I'd settle for a setting per list, but ideally it'd be a setting per user. > > I'm not sure how hard it would be for mailman to do that. > > If they insist on continued munging, allow them to Feel Their Own Pain. > > They're entitled. Yep, except that I get to be on the damn list too :-( Marc -- 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 redesdemercadeo@tutopia.com Tue Aug 21 00:21:21 2001 From: redesdemercadeo@tutopia.com (jose luis gonzalez) Date: Mon, 20 Aug 2001 17:21:21 -0600 Subject: [Mailman-Developers] is ok confirm 448239 Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C1299C.8842CA00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit SALUDOS DESDE MEXICO.....toma jugo "Noni".......... visita www.morinda.com # de patrocinador 782700 Powered by MediaRing ------=_NextPart_000_0000_01C1299C.8842CA00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
SALUDOS DESDE =
MEXICO.....toma jugo "Noni"..........
visita   www.morinda.com    # de =
patrocinador 782700
3D"Record
Powered by MediaRing
 
------=_NextPart_000_0000_01C1299C.8842CA00-- From barry@zope.com Tue Aug 21 01:07:24 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 20 Aug 2001 20:07:24 -0400 Subject: [Mailman-Developers] 2.1 eta? References: <15233.27269.843024.779688@anthem.wooz.org> Message-ID: <15233.42556.401640.786223@anthem.wooz.org> >>>>> "DN" == Dale Newfield writes: DN> Ahh. I didn't realize the time-scale involved. It may well be sooner, I'm just trying to be conservative. Too many factors outside my control! DN> I'm setting up a new machine to run a handful of domains, and DN> have been delaying the completion of various bits until MM2.1. DN> Clearly that's not a good idea. DN> MM won't be incredibly taxed by this installation--a handful DN> of small lists and one fairly large (<5000 subscribers) DN> announcement-only list. How stupid do you think it would be DN> to use a3 on this site, and then upgrade as bits become DN> available? How easy would it be to do that--is it possible to DN> simply check stuff directly out of the CVS tree, so that I'll DN> be able simply "cvs update" to merge in updates? Would it be DN> a bad idea to merge in updates on a live installation? One thing to watch out for is incompatible changes between alpha releases. I reserve the right not to worry about smooth upgrades between alphas for things like .db file format changes, etc. I don't /forsee/ any such changes, but I don't want to commit to that until we go to beta. Once in beta, I will try quite hard to either remain file format compatible, or provide and automatic upgrade path from one beta to the next (and certainly from 2.0.6 -> 2.1). If you're willing to assume that responsibility, you may not have such a hard time. -Barry From barry@zope.com Tue Aug 21 01:08:08 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 20 Aug 2001 20:08:08 -0400 Subject: [Mailman-Developers] 2.1 eta? References: Message-ID: <15233.42600.757163.91981@anthem.wooz.org> >>>>> "MC" == Mentor Cana writes: MC> I the stability of the 2.1 betas can be judged by the MC> stability of 2.0 betas Thanks. Hopefully this time the beta cycle will be /much/ shorter. :) -Barry From barry@zope.com Tue Aug 21 01:08:56 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 20 Aug 2001 20:08:56 -0400 Subject: [Mailman-Developers] 2.1 eta? References: <20010820120938.T26783@mrbill.net> <5.1.0.14.2.20010820135843.045cbc40@lennier.cc.vt.edu> <15233.27269.843024.779688@anthem.wooz.org> <20010820224131.714fc0d3.ricardo@rixhq.nu> Message-ID: <15233.42648.863434.862246@anthem.wooz.org> >>>>> "RFK" == Ricardo F Kustner writes: RFK> ah nice... you can count on me to start debugging it on a RFK> production environment starting form MM2.1 b1 :-) Excellent! I'm going to be pretty strict about feature freezes during beta though. I was really unhappy at my lack of resolve during the 2.0 beta cycle. -Barry From Dale Newfield Tue Aug 21 01:41:28 2001 From: Dale Newfield (Dale Newfield) Date: Mon, 20 Aug 2001 20:41:28 -0400 (EDT) Subject: [Mailman-Developers] 2.1 eta? In-Reply-To: <15233.42556.401640.786223@anthem.wooz.org> Message-ID: On Mon, 20 Aug 2001, Barry A. Warsaw wrote: > One thing to watch out for is incompatible changes between alpha > releases. I reserve the right not to worry about smooth upgrades > between alphas for things like .db file format changes, etc. I don't > /forsee/ any such changes, but I don't want to commit to that until we > go to beta. Once in beta, I will try quite hard to either remain file > format compatible, or provide and automatic upgrade path from one beta > to the next (and certainly from 2.0.6 -> 2.1). So I will take that as a warning and also wait until the 2.1 beta (rather than a3), and just set everything up right now with 2.0.6. Then I'll be a guinea pig through the beta cycle for 2.1. Thanks for all your efforts--this is a wonderful package that only seems to be getting even better! -Dale From barry@zope.com Tue Aug 21 03:42:14 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 20 Aug 2001 22:42:14 -0400 Subject: [Mailman-Developers] 2.1 eta? References: <15233.42556.401640.786223@anthem.wooz.org> Message-ID: <15233.51846.642238.230045@anthem.wooz.org> >>>>> "DN" == Dale Newfield writes: DN> So I will take that as a warning and also wait until the 2.1 DN> beta (rather than a3), and just set everything up right now DN> with 2.0.6. Then I'll be a guinea pig through the beta cycle DN> for 2.1. Sounds good. DN> Thanks for all your efforts--this is a wonderful package that DN> only seems to be getting even better! Thanks! -Barry From barry@zope.com Tue Aug 21 05:41:32 2001 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 21 Aug 2001 00:41:32 -0400 Subject: [Mailman-Developers] Results from 2.1a2's /mailman/create ... not as expected References: <000101c117e1$e8bc0080$0401a8c0@ibmpeers> Message-ID: <15233.59004.631575.509089@anthem.wooz.org> >>>>> "SB" == Scott Brown writes: SB> I dont know if this was by design or not, but I went to my SB> (not externally accessible) test system at SB> http://www.testdomain.com/mailman/create and created a list SB> "justatest" and got the message tacked on the bottom of this SB> message. SB> Things that "JustDontLookRight" to me include: SB> - picked up the server's name, rather than the domain name of SB> the host it was triggered under. SB> Could it not be set up to take the virtual host underwhich it SB> was triggered (ie, testdomain.com), and use that as the SB> prefered name of the list? The next page that comes up is SB> listed as being under that virtual host -- but all the links SB> point back to the machine's name. See the latest cvs. If you add add_virtualhost() calls to your mm_cfg.py file, this should all now work. I think this is what you meant (in private email) about cheap-'n'-easy virtual hosts. The intent is to do everything we can to support virtual hosts in MM2.1, short of eliminating the restriction of unique list names across the entire site. That I'm punting on until after MM2.1. SB> - Required me to use the sitepassword to create a new list... SB> How can I give that priveledge to someone else (like a virtual SB> host admin)... I've not found any documentation anywhere that SB> describes how to register a valid user under a domain (such SB> that they can only create lists under that domain) You should be able to set the "list creator's" password by using the -c option to bin/mmsitepass. This doesn't let you hand out unique list creation privileges per virtual domain, but it does let you delegate those privileges to folks who won't have site admin access. SB> - last line in message didnt have proper replacement of SB> "hostname". SB> Just a buglet - but I dont know enough python to fix it.... Should be fixed now. SB> - The email that is produced with the /etc/alias SB> additions... is it possible to define where that goes, say in SB> the mm_cfg.py? SB> It would be nice to be able to pipe those specific through SB> another email address that triggers a routine that could SB> actually do the append as root... Currently it's hard coded to the "site owner" address, typically mailman@your.dom.ain, where the LHS is defined by MAILMAN_SITE_LIST and the RHS is defined by mappings in VIRTUAL_HOSTS (configured by add_virtualhost() calls). Don't change MAILMAN_SITE_LIST just to change this behavior; for now hack Mailman/MTA/Manual.py to change the destination address. -Barry From barry@zope.com Tue Aug 21 05:52:01 2001 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 21 Aug 2001 00:52:01 -0400 Subject: [Mailman-Developers] mailman 2.1a2 -- mailmanctl -- memory usage References: <15229.45732.786649.840142@anthem.wooz.org> <001901c1277f$8291af00$0401a8c0@ibmpeers> Message-ID: <15233.59633.641702.525050@anthem.wooz.org> >>>>> "SB" == Scott Brown writes: SB> In a perfect world, yes, that would be the best (I mentioned SB> this on the wikki)... but if you were to look at sliding vhost SB> support in gradually (which is a reasonable expectation SB> considering how much could be upset in an all-or-nothing SB> change set) then I dont see a problem with the SB> unique-list-names-per-server approach at this time (I've got SB> that same limitation on my prod server right now with the way SB> things are setup... no-one seems to care about that SB> limitation... and I'm sure that knowing that v2.2 (or v3.0) SB> would have this restriction removed would placeate most people SB> who might get their shorts in a knot). Cool, I can live with that too, then! :) SB> I guess it falls back to the business model. Of course, if SB> you're REALLY wanting to make an inroads into a vhosting SB> environment, then you'd also need to be able to configure the SB> max lists allowed per domain. Me - personally - SB> "IDontCare"(tm) if someone has 1 or 100. I have plans on how to do this, and support something that Chuq's talked about a lot. The idea is that you really have these levels of control: site -> vhost -> list (are there more?). You want the site admin to be able to say "I'll let my vhost admins change option W and X, but not Y, and limit Z to from 1 to 100". I believe that's doable, but definitely not in the MM2.1 time frame. Next year. :) >> - DEFAULT_HOST_NAME vs. DEFAULT_URL. Each vhost is identified >> by both variables (e.g. mail.python.org and list@python.org). >> So you need to create a mapping of vhost to those two >> variables, and use the right one in the right context. SB> True enough - but both are (something)python.org. Right now, SB> unless you override things, you get default_host as 'hostname' SB> and default_url as http://'hostname'/mailman/ ... spitting the SB> vhost name into either one is a heck of a lot closer than SB> 'hostname'. SB> And it would only be necessary on creation of new records, no? SB> Once the data's there, it could be modified by the user, so SB> current processes would (to my mind) still hold up. No. What we're talking about are the list config attributes web_page_url and host_name. The former gets used in all generated URLs, such as http://mail.python.org/mailman/listinfo and the latter gets used in all email, e.g. mailman-developers-request@python.org. Anyway, it's way too dangerous to let list admins muck with web_page_url, since it's trivial to make their lists non-functional. And I see no reason why they should be able to muck with host_name either. So both are frozen when the list is created (of course, they can always be changed via bin/withlist. So, the new deal is to define the web_page_url/host_name (really, the host that is embedded in web_page_url) mappings in mm_cfg.py with calls to add_virtualhost() and then everything should work fine from there. SB> MM2.1 is already including a number of goodies that will be SB> useful... and I'm probably as anxious as you to get a release SB> version out... Probably not. :) Cheers, -Barry From jra@baylink.com Tue Aug 21 15:05:01 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 21 Aug 2001 10:05:01 -0400 Subject: [Mailman-Developers] Patching qrunner to never send duplicates w/ same Message-ID In-Reply-To: <20010820142753.F22426@magic.merlins.org>; from Marc MERLIN on Mon, Aug 20, 2001 at 02:27:53PM -0700 References: <15233.8728.923029.568314@anthem.wooz.org> <20010820105945.10636@scfn.thpl.lib.fl.us> <15233.10765.367781.639149@anthem.wooz.org> <20010820121417.03731@scfn.thpl.lib.fl.us> <15233.15148.535006.951339@anthem.wooz.org> <20010820130355.11877@scfn.thpl.lib.fl.us> <15233.22640.481533.421976@anthem.wooz.org> <20010820114812.D22426@magic.merlins.org> <20010820150710.54092@scfn.thpl.lib.fl.us> <20010820142753.F22426@magic.merlins.org> Message-ID: <20010821100501.57944@scfn.thpl.lib.fl.us> On Mon, Aug 20, 2001 at 02:27:53PM -0700, Marc MERLIN wrote: > On Mon, Aug 20, 2001 at 03:07:10PM -0400, Jay R. Ashworth wrote: > > > While we are on this topic, I would really love for a way for mailman to > > > optionally parse the Cc and To lines and not send a post to a subscribed > ^^^^^^^^^^ > > > address if that address was already in the headers. > > > > Nope; not unless it's configurable. That's actually what we were just > > I said "optionally". > I'd settle for a setting per list, but ideally it'd be a setting per user. You did. I'd *greatly* prefer this to be per-user; I'm sufficiently stringent on "the proper behavior of mailing lists" that I probably would shun lists that automagically didn't send me back my own traffic, just as I shun lists operated by people who do nasty things with their subscriber info... regardles of *how* much I am interested in the content. You can treat that observation as a datapoint in the "yes, there really are people like that out there" category. :-) > > > I'm not sure how hard it would be for mailman to do that. > > > > If they insist on continued munging, allow them to Feel Their Own Pain. > > > > They're entitled. > > Yep, except that I get to be on the damn list too :-( My condolences. 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 804 5015 "So easy to use, no wonder the Internet is going to hell!" -- me From james_leone@yahoo.com Wed Aug 22 03:08:21 2001 From: james_leone@yahoo.com (James Leone) Date: Tue, 21 Aug 2001 19:08:21 -0700 (PDT) Subject: [Mailman-Developers] Handling Bouncebacks Message-ID: <20010822020821.58265.qmail@web13906.mail.yahoo.com> I'm interested in understanding how Mailman handles bounces and seeing if my previous MLM experience will allow me to make additions. I'm fresh to Python, but am familiar with Perl as well as Java and feel compfortable looking at the code, but need some reinforcement at the higher level of architecture. These questions should be easy. The email blast goes out and the bads ones come back to a specified address. Does Mailman run as a daemon or are bouncebacks handles by piping through the aliases file? Basically, where is the entry point for disecting the message and determining whether is looks like a bounced email or the user's mailbox is just full. I see that there is a Bouncer class, and an example api, but the comments are rather sparse. __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From Dan Mick Wed Aug 22 03:31:00 2001 From: Dan Mick (Dan Mick) Date: Tue, 21 Aug 2001 19:31:00 -0700 (PDT) Subject: [Mailman-Developers] Handling Bouncebacks Message-ID: <200108220230.TAA00229@utopia.West.Sun.COM> > These questions should be easy. > The email blast goes out and the bads ones come back > to a specified address. Does Mailman run as a daemon > or are bouncebacks handles by piping through the > aliases file? Aliases lead to the processing commands. The bounces come to -admin@. If you're talking about pre-2.1, see the comments at the head of cron/qrunner. Bounces go through the mailowner script (as a result of the alias). 2.1 and after use a different queue structure, essentially with daemons, but the daemons aren't listening for mail; they still get accessed via mail aliases which run programs which know how to send IPCs to talk to them. This stuff uses the Mailman/Queue code. Bounces still go through mailowner, but now mailowner calls the Switchboard queuing stuff. See Mailman/Queue/IncomingRunner.py for the diagram as it applies to 2.1. From barry@zope.com Wed Aug 22 04:02:27 2001 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 21 Aug 2001 23:02:27 -0400 Subject: [Mailman-Developers] Handling Bouncebacks References: <20010822020821.58265.qmail@web13906.mail.yahoo.com> Message-ID: <15235.8387.111752.64868@anthem.wooz.org> >>>>> "JL" == James Leone writes: JL> I'm interested in understanding how Mailman handles JL> bounces and seeing if my previous MLM experience will JL> allow me to make additions. Cool! JL> I'm fresh to Python, but am familiar with Perl as well JL> as Java and feel compfortable looking at the code, but JL> need some reinforcement at the higher level of JL> architecture. Given your experience, you should find Python a breeze. I predict total Pythonic conversion in, oh, two weeks. :) JL> These questions should be easy. The email blast goes out and JL> the bads ones come back to a specified address. Does Mailman JL> run as a daemon or are bouncebacks handles by piping through JL> the aliases file? JL> Basically, where is the entry point for disecting the message JL> and determining whether is looks like a bounced email or the JL> user's mailbox is just full. First, some background. I'm going to describe Mailman 2.1 here, since that's where the architecture is most robust. Every mailing list has a number of aliases installed which direct the MTA to pipe the message through one of the Mailman scripts (via a thin C security wrapper). These scripts all dump the message into a queue, and a daemon `qrunner' picks the messages up from the queue and processes them. It's done this way to ensure robustness, avoiding nasty timeout issues and uncatchable kill signals from certain MTAs in certain situations. The list of aliases are roughly: mylist - all user postings go here mylist-request - the command processor robot (i.e. `help') mylist-admin - the bounce processor robot, then to owners mylist-owner - list of human operators of the list mylist-join - auto-subscribe robot mylist-leave - auto-unsubscribe robot (BTW, It's easy to add others if we wanted.) So, all messages to mylist@dom.ain are resent with errors pointing to mylist-admin@dom.ain. Messages addressed to mylist-admin get dropped in "command" queue, and processed by the CommandRunner. For historical reasons, the CommandRunner processes all messages sent to mylist-owner and mylist-admin, and there is a metadata entry to tell CommandRunner which address the message was sent to (i.e. `toowner' or `toadmin' respectively). All messages with the `toadmin' key, i.e. mylist-admin, first get run through the bounce detector. If the bounce format matches one of the known patterns, any extracted addresses are entered into the bounce database. If no match was found, the message is handled exactly as if it were addressed to -owner, i.e. it's sent to the list owners directly. The extensible bounce detection subsystem is implemented as modules in Mailman/Bouncers, with Mailman/Bouncers/BouncerAPI.py as the main entry point. Specifically, the function BouncerAPI.ScanMessages() is handed the message and the MailList instance. It returns 1 if a bounce was detected and registered, and 0 if not. JL> I see that there is a Bouncer class, and an example JL> api, but the comments are rather sparse. The Bouncer class is really a mixin class for the MailList. It manages the bounce database and a few other bouncer functions, such as sending out the messages when a bouncing address is disabled, etc. It's fairly old code, and fairly crufty, and has been on my hit list for a rewrite for a while now. Note that the Bouncer class, as in Mailman/Bouncer.py isn't the API for the bounce detection system. Look at BouncerAPI.py for how the bounce detector gets run. Python doesn't (yet) have a widely accepted interface specification formalism, but here's how the bounce detector (i.e ScanMessage()) works. You'll see a list in the local variable `pipeline'. Each of these names a module in the Mailman.Bouncers package, and ScanMessage imports each dynamically in turn. In each module must be a process() function which takes a Message object. The process() function either returns a list of addresses -- which signals a successful detection of this bounce format -- or it returns a false value (note that in Python, an empty list is considered false), in which case that particular detector didn't find a match, and the next detector is imported and run. The first detector to extract an address wins. Note also, that BouncerAPI.py is designed to run as a script for testing purposes, but that's proven awkward, and the fledgling Mailman unit tests provide a better way to test the individual bounce detectors. I hope that helps! -Barry From che@debian.org Wed Aug 22 11:23:50 2001 From: che@debian.org (Ben Gertzfield) Date: Wed, 22 Aug 2001 19:23:50 +0900 Subject: [Mailman-Developers] Patching qrunner to never send duplicates w/ same Message-ID In-Reply-To: <15233.15148.535006.951339@anthem.wooz.org> (barry@zope.com's message of "Mon, 20 Aug 2001 12:30:36 -0400") References: <87pu9rs7r2.fsf@nausicaa.interq.or.jp> <15233.8728.923029.568314@anthem.wooz.org> <20010820105945.10636@scfn.thpl.lib.fl.us> <15233.10765.367781.639149@anthem.wooz.org> <20010820121417.03731@scfn.thpl.lib.fl.us> <15233.15148.535006.951339@anthem.wooz.org> Message-ID: <87lmkc9yvd.fsf@nausicaa.interq.or.jp> >>>>> "BAW" == Barry A Warsaw writes: >>>>> "JRA" == Jay R Ashworth writes: JRA> The user's option, certainly, but *I* want to know that copy JRA> made the list. I always leave meetoo set, too. I'd like to JRA> see mailers that can, like Mutt, reply to the list wihtout JRA> *having* to carbon the other user, since that's where most JRA> dupes -- like yourn :-) -- come from. BAW> It's a sticky issue. How does my MUA (XEmacs/VM BTW) know BAW> that jra@baylink.com is actually on the BAW> mailman-developers@python.org list? You set Mail-Followups-To: never in your headers. Ben -- Brought to you by the letters C and O and the number 3. "Killer refresh rate! It's even got a PCI bus!" Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From alaric@babcom.com Thu Aug 23 06:26:16 2001 From: alaric@babcom.com (Phil Stracchino) Date: Wed, 22 Aug 2001 22:26:16 -0700 Subject: [Mailman-Developers] Read-only lists and per-user moderation Message-ID: <20010822222616.D3866@babylon5.babcom.com> I see the question of the read-only mailing list has arisen yet again. How difficult would it actually be to add this functionality? I see two approaches to doing it. The first would be to just add a per-list "read-only" attribute. If this attribute is enabled, then the "Addresses of members accepted for posting to this list without implicit approval requirement" list becomes a list of users authorized to post to the list, period, and all other posts would be rejected automatically without generating an admin request to the list owner. The second, more flexible approach would be to add the per-list read-only attribute *and* add a per-user "Posting OK" flag to the Membership Management screen, which would default to on and could be set or cleared only by the list owner. Setting the list's read-only attribute would cause the "Posting OK" flag to be turned off for all existing members except the list owner, and cause all new subscriptions to have "Posting OK" turned off by default. This second implementation would also allow the list owner of a normal read-write list to selectively revoke posting privileges for list members without actually kicking them off the list. Used in this way, it would effectively amount to turning on moderation on a per-user basis without having to add all other members to the "approval not required" list. Reasons for doing this might include disciplinary measures for disruptive members, handling members who go on vacation with a vacation program set and forget to set their subscription to no-deliver, as a way to quickly squelch a flame war without having to turn on moderation for the entire list, or to set up a scheme of "probationary" members whereby posting privileges are not granted until a member has been subscribed for a specified period in order to learn the norms of accepted behavior on the list. Thoughts, opinions, flames? -- Linux Now! ..........Because friends don't let friends use Microsoft. phil stracchino -- the renaissance man -- mystic zen biker geek alaric@babcom.com halmayne@sourceforge.net 2000 CBR929RR, 1991 VFR750F3 (foully murdered), 1986 VF500F (sold) From nb@thinkcoach.com Thu Aug 23 15:56:56 2001 From: nb@thinkcoach.com (Norbert Bollow) Date: Thu, 23 Aug 2001 16:56:56 +0200 Subject: [Mailman-Developers] Handling Bouncebacks In-Reply-To: <20010822020821.58265.qmail@web13906.mail.yahoo.com> (message from James Leone on Tue, 21 Aug 2001 19:08:21 -0700 (PDT)) References: <20010822020821.58265.qmail@web13906.mail.yahoo.com> Message-ID: <200108231456.f7NEuun04798@quill.local> > I'm interested in understanding how Mailman handles > bounces It essentially tries to parse them, in order to determine which address is creating the problems. This is not ideal. This behavior is what I would like to have: If the MTA is Qmail, which supports VERP without any loss of performance, VERPs should be used always. On other MTAs (where VERPing is expensive) you can use VERP on say 5% of each batch of outgoing messages. Every 20th message to each address will have VERP. Then you can use out-of-band warnings and probes (like Ezmlm does) to see if the address remains invalid for a long time. > Basically, where is the entry point for disecting the > message and determining whether is looks like a > bounced email or the user's mailbox is just full. Please take into account that "mailbox full" errors are sometimes permanent, and "user unknown" errors are sometimes temporary. Greetings, Norbert. -- A member of FreeDevelopers and the DotGNU Steering Committee: dotgnu.org Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland) Tel +41 1 972 20 59 Fax +41 1 972 20 69 http://thinkcoach.com Your own domain with all your Mailman lists: $15/month http://cisto.com From claw@kanga.nu Thu Aug 23 17:53:06 2001 From: claw@kanga.nu (J C Lawrence) Date: Thu, 23 Aug 2001 09:53:06 -0700 Subject: [Mailman-Developers] Handling Bouncebacks In-Reply-To: Message from Norbert Bollow of "Thu, 23 Aug 2001 16:56:56 +0200." <200108231456.f7NEuun04798@quill.local> References: <20010822020821.58265.qmail@web13906.mail.yahoo.com> <200108231456.f7NEuun04798@quill.local> Message-ID: <19530.998585586@kanga.nu> On Thu, 23 Aug 2001 16:56:56 +0200 Norbert Bollow wrote: > If the MTA is Qmail, which supports VERP without any loss of > performance, VERPs should be used always. Performance is not the only concern or criteria. Bandwidth utilisation, mail routing (what says that the MTA Mailman delivers to is responsible for delivery to the final MX?), local resource consumption, and a small host of other concerns dictate this area far more than the choice of MTA. -- J C Lawrence )\._.,--....,'``. ---------(*) /, _.. \ _\ ;`._ ,. claw@kanga.nu `._.-(,_..'--(,_..'`-.;.' http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly From nb@thinkcoach.com Thu Aug 23 17:57:32 2001 From: nb@thinkcoach.com (Norbert Bollow) Date: Thu, 23 Aug 2001 18:57:32 +0200 Subject: [Mailman-Developers] Handling Bouncebacks In-Reply-To: <19530.998585586@kanga.nu> (message from J C Lawrence on Thu, 23 Aug 2001 09:53:06 -0700) References: <20010822020821.58265.qmail@web13906.mail.yahoo.com> <200108231456.f7NEuun04798@quill.local> <19530.998585586@kanga.nu> Message-ID: <200108231657.f7NGvWJ01619@quill.local> > > If the MTA is Qmail, which supports VERP without any loss of > > performance, VERPs should be used always. > > Performance is not the only concern or criteria. Bandwidth > utilisation, mail routing (what says that the MTA Mailman delivers > to is responsible for delivery to the final MX?), local resource > consumption, and a small host of other concerns dictate this area > far more than the choice of MTA. Maybe I used the wrong word (for me "performance" takes into account all resources that are used, including bandwidth). My point is that since Qmail always uses single-message envelopes anyway, IF the MTA is Qmail, then it does _not_ cost you _anything_ to use VERPs. Greetings, Norbert. -- A member of FreeDevelopers and the DotGNU Steering Committee: dotgnu.org Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland) Tel +41 1 972 20 59 Fax +41 1 972 20 69 http://thinkcoach.com Your own domain with all your Mailman lists: $15/month http://cisto.com From claw@kanga.nu Thu Aug 23 18:12:35 2001 From: claw@kanga.nu (J C Lawrence) Date: Thu, 23 Aug 2001 10:12:35 -0700 Subject: [Mailman-Developers] Handling Bouncebacks In-Reply-To: Message from Norbert Bollow of "Thu, 23 Aug 2001 18:57:32 +0200." <200108231657.f7NGvWJ01619@quill.local> References: <20010822020821.58265.qmail@web13906.mail.yahoo.com> <200108231456.f7NEuun04798@quill.local> <19530.998585586@kanga.nu> <200108231657.f7NGvWJ01619@quill.local> Message-ID: <19942.998586755@kanga.nu> On Thu, 23 Aug 2001 18:57:32 +0200 Norbert Bollow wrote: > My point is that since Qmail always uses single-message envelopes > anyway, IF the MTA is Qmail, then it does _not_ cost you > _anything_ to use VERPs. Does QMail always use single message envelopes when it is configured to deliver all outbound mail to a (single) smarthost? -- J C Lawrence )\._.,--....,'``. ---------(*) /, _.. \ _\ ;`._ ,. claw@kanga.nu `._.-(,_..'--(,_..'`-.;.' http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly From nb@thinkcoach.com Thu Aug 23 18:44:01 2001 From: nb@thinkcoach.com (Norbert Bollow) Date: Thu, 23 Aug 2001 19:44:01 +0200 Subject: [Mailman-Developers] Handling Bouncebacks In-Reply-To: <19942.998586755@kanga.nu> (message from J C Lawrence on Thu, 23 Aug 2001 10:12:35 -0700) References: <20010822020821.58265.qmail@web13906.mail.yahoo.com> <200108231456.f7NEuun04798@quill.local> <19530.998585586@kanga.nu> <200108231657.f7NGvWJ01619@quill.local> <19942.998586755@kanga.nu> Message-ID: <200108231744.f7NHi1L02095@quill.local> J C Lawrence wrote: > Does QMail always use single message envelopes when it is configured > to deliver all outbound mail to a (single) smarthost? Yes. Qmail always uses single message envelopes. In the Qmail world, smarthosting for mailing list traffic is normally implemented with Ezmlm, in a way that is more efficient than what you can done in any way with SMTP-based smarthosting. Greetings, Norbert. -- A member of FreeDevelopers and the DotGNU Steering Committee: dotgnu.org Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland) Tel +41 1 972 20 59 Fax +41 1 972 20 69 http://thinkcoach.com Your own domain with all your Mailman lists: $15/month http://cisto.com From claw@kanga.nu Thu Aug 23 19:42:53 2001 From: claw@kanga.nu (J C Lawrence) Date: Thu, 23 Aug 2001 11:42:53 -0700 Subject: [Mailman-Developers] Handling Bouncebacks In-Reply-To: Message from Norbert Bollow of "Thu, 23 Aug 2001 19:44:01 +0200." <200108231744.f7NHi1L02095@quill.local> References: <20010822020821.58265.qmail@web13906.mail.yahoo.com> <200108231456.f7NEuun04798@quill.local> <19530.998585586@kanga.nu> <200108231657.f7NGvWJ01619@quill.local> <19942.998586755@kanga.nu> <200108231744.f7NHi1L02095@quill.local> Message-ID: <21101.998592173@kanga.nu> On Thu, 23 Aug 2001 19:44:01 +0200 Norbert Bollow wrote: > J C Lawrence wrote: >> Does QMail always use single message envelopes when it is >> configured to deliver all outbound mail to a (single) smarthost? > Yes. Qmail always uses single message envelopes. Can it be configured *NOT* to? > In the Qmail world, smarthosting for mailing list traffic is > normally implemented with Ezmlm, in a way that is more efficient > than what you can done in any way with SMTP-based smarthosting. Which is not necessarily the point. With ISP's blocking outbound SMTP traffic and thereby forcing use of their smarthosts along with corporate network infrastructures and security models effectively ending at the same spot, the ability to use multi-address envelopes can be critical. I'm curious if this is a corner which Qmail is incapable is satisfying. -- J C Lawrence )\._.,--....,'``. ---------(*) /, _.. \ _\ ;`._ ,. claw@kanga.nu `._.-(,_..'--(,_..'`-.;.' http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly From benwa@ocentrix.com Thu Aug 23 20:53:37 2001 From: benwa@ocentrix.com (Ben Burnett) Date: Thu, 23 Aug 2001 12:53:37 -0700 Subject: [Mailman-Developers] Preferred Feedback Pipeline Message-ID: <5.1.0.14.0.20010823121154.00ac45c0@mail.ocentrix.com> Hey Barry, I'm posting this on the list because I think it would be relevant for everyone to know. What is you're preferred pipeline for feedback on Mailman, especially feedback on testing the development releases? The reason I ask is that it seems that there are quite a few different places that could be used. The sourceforge site. bugs, patches, feature requests http://www.sourceforge.net/projects/mailman The discussion lists. much and many of everything. mailman-users@python.org, mailman-developers@python.org The wiki. requirements, architectural directions, component designs, more http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/FrontPage Did I miss any? Perhaps you'd prefer a different venue and format for different types of feedback. While I don't expect to be able to have 100% of all feedback redirected perhaps if we put your preferred methods in the FAQ, README, and the devs.html, bugs.html, and todo.html pages of the Mailman site a good portion could be redirected. feature request: sourceforge? bug report: sourceforge? patches: sourceforge? usage questions: mailman-users? development questions: mailman-developers, wiki? praise: ? rant's, demands, whining: /dev/null? money: ? Am I making an issue out of a non-issue? - Ben From nb@thinkcoach.com Fri Aug 24 16:11:14 2001 From: nb@thinkcoach.com (Norbert Bollow) Date: Fri, 24 Aug 2001 17:11:14 +0200 Subject: [Mailman-Developers] Handling Bouncebacks In-Reply-To: <21101.998592173@kanga.nu> (message from J C Lawrence on Thu, 23 Aug 2001 11:42:53 -0700) References: <20010822020821.58265.qmail@web13906.mail.yahoo.com> <200108231456.f7NEuun04798@quill.local> <19530.998585586@kanga.nu> <200108231657.f7NGvWJ01619@quill.local> <19942.998586755@kanga.nu> <200108231744.f7NHi1L02095@quill.local> <21101.998592173@kanga.nu> Message-ID: <200108241511.f7OFBEk08557@quill.local> > > Yes. Qmail always uses single message envelopes. > > Can it be configured *NOT* to? I'm pretty sure that this is not possible. > > In the Qmail world, smarthosting for mailing list traffic is > > normally implemented with Ezmlm, in a way that is more efficient > > than what you can done in any way with SMTP-based smarthosting. > > Which is not necessarily the point. With ISP's blocking outbound > SMTP traffic and thereby forcing use of their smarthosts along with > corporate network infrastructures and security models effectively > ending at the same spot, the ability to use multi-address envelopes > can be critical. I'm curious if this is a corner which Qmail is > incapable is satisfying. Hmm... you're probably right about that. Qmail is probably not a good choice in that kind of situation. But then, does one really have to put up with an ISP which blocks outbound SMTP traffic? I wouldn't. :-) But my point remains: *If* the MTA is Qmail, *then* using VERPs will not introduce any significant overhead of any kind. Greetings, Norbert. -- A member of FreeDevelopers and the DotGNU Steering Committee: dotgnu.org Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland) Tel +41 1 972 20 59 Fax +41 1 972 20 69 http://thinkcoach.com Your own domain with all your Mailman lists: $15/month http://cisto.com From Dale Newfield Fri Aug 24 16:32:18 2001 From: Dale Newfield (Dale Newfield) Date: Fri, 24 Aug 2001 11:32:18 -0400 (EDT) Subject: [Mailman-Developers] List-CC? In-Reply-To: <5.1.0.14.0.20010823121154.00ac45c0@mail.ocentrix.com> Message-ID: I've got another fairly simple idea that I figured I'd throw out for comment. I was about to send a note to an announcement list I run, and thought "hey, I should also send this to Bob." Problem is, if I CC or BCC Bob, he gets the mail I send to Mailman rather than the mail that Mailman would send out (with the subscription info/footer/etc.) What would be cool is if there were a way to List-BCC: people instead of BCC:'ing them. Then Mailman would be the one to distribute extra copies, and they could be the same as messages seen by list-subscribers. -Dale From REBECCA GANDHEART" InternalAntennas.com
 
 

ANTENNABOOSTER.NET
PO BOX 972723
EL PASO TX 799972723

SHIPPING-DEPT@PRODIGY.NET
(915)633 -8083 9AM TO 8PM M-F MST

-----Original Message-----
From: Brenda Roundtree [mailto:mrswireless@mail.com]
Sent: Thursday, August 23, 2001 1:39 PM
To: members.only@pimout3-int.prodigy.net
Subject: Test


Home of the FREE Antena Booster!



FREE ANTENNA BOOSTER FOR YOUR CELL PHONE!
AS SEEN IN LAPTOP MAGAZINE!




INTERNALANTENNAS.COM

Go to InternalAntennas.com to order your






We sell over 10,000 Version II antennas a month for a good reason,
OUR PRODUCT WORKS! we have technical support FOR CUSTOMERS & 10 years
of wireless experience in tower construction for cellular & PCS sites. We dont just
sell you the product we stand behind it.... We have thousands of satisfied customers
read our testimonials and you will see why we are the main supplier of internal
antennas to local dept stores , dollar stores and wireless retail centers
ALL OVER NORTH AMERICA

Enjoy our expertise...
Brand New ! Version II eclusive to 2001 Technology Services do not accept imitations

The Internal Booster Antenna is a passive device designed to capture the
stray radiation inside the body of the phone and re-direct the signal to
improve the phone's performance. Now you can use your cell phone in abnk
vaults, elevators, cars, boats, mountains, ski resorts, tunnels, buildings and more.....
It's like having a FIVE foot antenna on your phone.

Great for Bad Areas, Boats, Mountains, Elevators, Car, Building Etc

Works on any cellular phone.

Very easy to install!!

Clears up static and make everything clear.
Enjoy the reduced static and enhanced signal on your cellular phone!!

Retails ON TV for $19.95 to $29.95







All our mailings are sent complying to the proposed United States Federal requirements for
commercial e-mail: Section 301 Paragraph (a)(2)(C) of S. 618.
Please see the bottom of this message for further information and removal instructions.

Contact: POWER@elp.rr.com and you will be removed immediately!
TITLE YOUR EMAIL: REMOVE ME
From benwa@ocentrix.com Fri Aug 24 19:15:16 2001 From: benwa@ocentrix.com (Ben Burnett) Date: Fri, 24 Aug 2001 11:15:16 -0700 Subject: [Mailman-Developers] List-CC? In-Reply-To: References: <5.1.0.14.0.20010823121154.00ac45c0@mail.ocentrix.com> Message-ID: <5.1.0.14.0.20010824111403.00a2c050@mail.ocentrix.com> At 11:32 AM 8/24/2001 -0400, Dale Newfield wrote: >I've got another fairly simple idea that I figured I'd throw out for >comment. I was about to send a note to an announcement list I run, and >thought "hey, I should also send this to Bob." Problem is, if I CC or BCC >Bob, he gets the mail I send to Mailman rather than the mail that Mailman >would send out (with the subscription info/footer/etc.) What would be >cool is if there were a way to List-BCC: people instead of BCC:'ing them. >Then Mailman would be the one to distribute extra copies, and they could >be the same as messages seen by list-subscribers. Maybe I'm missing something but this sounds like a setup for a spam relay. - Ben From benwa@ocentrix.com Fri Aug 24 20:48:03 2001 From: benwa@ocentrix.com (Ben Burnett) Date: Fri, 24 Aug 2001 12:48:03 -0700 Subject: [Mailman-Developers] List-CC? In-Reply-To: References: <5.1.0.14.0.20010824111403.00a2c050@mail.ocentrix.com> Message-ID: <5.1.0.14.0.20010824120510.00a9b350@mail.ocentrix.com> At 02:33 PM 8/24/2001 -0400, Dale Newfield wrote: >On Fri, 24 Aug 2001, Ben Burnett wrote: > > Maybe I'm missing something but this sounds like a setup for a spam > > relay. > >No more so than any mailing list--you can still have the same posting >restrictions. I'd use it so people can get a taste of what subscribing to >a given list is like w/o actually doing so. I guess I was missing something. For a moderated list this could be a neat feature. I also think that some people might receive the message and have no clue why they were included. They might think that they were subscribed by someone else, and get irate. Of course the list admins would then be subject to their wrath: "Why are you running a list that lets other people subscribe you without confirmation? I tried to unsubscribe, but it told me that I wasn't subscribed. Whats up with that!!" I think this could be cleared up with a "list sample" header/footer that was pre/appended to the message. Something like... ---- Greetings , This is a sample from the email list. Your friend who is subscribed to this list though you might be interested in seeing what goes on here. If you like what you see and would like to join the list just reply to this message with subscribe in the subject and you're all set. ---- Of course this seems like a little more work than just sending your message to the list and your friend, or if you really want them to get the entire list message, just wait for your copy from the list and forward it. - Ben From Dale Newfield Fri Aug 24 21:10:22 2001 From: Dale Newfield (Dale Newfield) Date: Fri, 24 Aug 2001 16:10:22 -0400 (EDT) Subject: [Mailman-Developers] List-CC? In-Reply-To: <5.1.0.14.0.20010824120510.00a9b350@mail.ocentrix.com> Message-ID: On Fri, 24 Aug 2001, Ben Burnett wrote: > or if you really want them to get the entire list message, just wait > for your copy from the list and forward it. That is the most sensible solution (and what I normally do), but it means the composition of the note and the forwarding are two separate steps necessarily separated in time. (The benefit, of course, is that when you forward it you can include a note like: "Hey, Bob--this is the kind of stuff we send to this list. See the bottom if you wanna subscribe.") I was thinking that it would be cool, however, to be able to compose the note and specify all its intended destinations in one fell swoop. I guess if there was List-CC: (but no List-BCC:) then it would address the "Why'd I get this?!" complaints, w/o having to insert a special disclaimer... (It would also alert the other readers that the message was seen by others, just like a CC: line does.) -Dale From jwblist@olympus.net Sun Aug 26 06:54:38 2001 From: jwblist@olympus.net (John W Baxter) Date: Sat, 25 Aug 2001 22:54:38 -0700 Subject: [Mailman-Developers] Read-only lists and per-user moderation In-Reply-To: <20010822222616.D3866@babylon5.babcom.com> References: <20010822222616.D3866@babylon5.babcom.com> Message-ID: At 22:26 -0700 8/22/2001, Phil Stracchino wrote: >I see two approaches to doing it. The first would be to just add a >per-list "read-only" attribute. If this attribute is enabled, then the >"Addresses of members accepted for posting to this list without implicit >approval requirement" list becomes a list of users authorized to post to >the list, period, and all other posts would be rejected automatically >without generating an admin request to the list owner. What place which cannot be forged does the sender information come from? --John -- John Baxter jwblist@olympus.net Port Ludlow, WA, USA From carson@taltos.org Sun Aug 26 20:22:27 2001 From: carson@taltos.org (Carson Gaspar) Date: Sun, 26 Aug 2001 12:22:27 -0700 Subject: [Mailman-Developers] Handling Bouncebacks In-Reply-To: <15235.8387.111752.64868@anthem.wooz.org> References: <15235.8387.111752.64868@anthem.wooz.org> Message-ID: <381104468.998828547@athyra> --On Tuesday, August 21, 2001 11:02 PM -0400 "Barry A. Warsaw" wrote: > The extensible bounce detection subsystem is implemented as modules in > Mailman/Bouncers, with Mailman/Bouncers/BouncerAPI.py as the main > entry point. Specifically, the function BouncerAPI.ScanMessages() is > handed the message and the MailList instance. It returns 1 if a > bounce was detected and registered, and 0 if not. Is it still this broken in 2.1? I thought you were going to add an "I parsed the bounce, and it was non-fatal, so please ignore it" return code. Right now, I either get swamped with non-fatals to -admin, or I unsub users for transient errors. Blech. -- Carson Gaspar - carson@taltos.org Queen Trapped in a Butch Body From chuqui@plaidworks.com Mon Aug 27 17:27:30 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 27 Aug 2001 09:27:30 -0700 Subject: [Mailman-Developers] Preventing spam to list admins. Message-ID: I have a feeling I'm opening up another can of worms for Barry, but... Had an interesting issue with a list admin this morning. One of his user had started getting spam, and because of various coincidences, thought it was because our subscriber list had leaked. I did a little snooping, and found that his address had been put on a public web page (not one of mine), and showed him that it was likely harvested there. At which point, the admin of the list involved wrote and asked how to get his address off of the info page for the lists he admins. After all, if you go to .../mailman/listinfo/listname, down at the bottom, the admin addresses are out there for all to see (and harvest). And -- I don't have an answer for that. But -- it's a legitimate problem. You can't exactly hide those pages behind a security realm. As Mailman is structured, you can't really remove them, and there's no way to protect them. But they need to be, because those pages are wide open, and accessible to all the spiders, so they're going to leak into the global search engines, or be harvested directly. Ugh. This has to be fixed in 2.1, if not before. I think the answer is to hide the e-mail addresses in some way, probably by having a mail-to-the-admin CGI, where only the admin's NAME is accessible publically, and Mailman handles forwarding mail to them. In retrospect, this problem is painfully obvious to me, but personally, I'm simply numb to having my e-mail address harvestable. But I think, in general, it's a bad idea to put any e-mail address on a page, and I think you can't programmatically obfuscate stuff, either (it'll be interesting to see whether slashdot's new random-obfuscate system actually works, or whether the harvesters will simply be able to figure out how it's obfuscated and eat the addresses anyway... I'm not hopeful) What do others think? Anyone got any quick ideas on how to dela with this, and what we ought to do long term? -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. USENET is a lot better after two or three eggnogs. We shouldn't allow anyone on the net without a bottle of brandy. (chuq von rospach, 1992) From joe.holt@netrequisite.com Mon Aug 27 17:26:21 2001 From: joe.holt@netrequisite.com (Joe Holt) Date: Mon, 27 Aug 2001 09:26:21 -0700 Subject: [Mailman-Developers] Re: List-CC? References: Message-ID: <3B8A74AD.D7FCE285@netrequisite.com> This is an issue that I would very much like to find a solution for. As I understand it, most list admins set their lists to not accept email cc'ed or bcc'ed to the list. Very often I find myself wanting to send an event announcement or some such to several addresses (at least one of which is a list) without exposing everyone's email in the 'To:' header. I have to create a separate email for lists that use Mailman. I have actually never received a spam through an email list but it must be a problem for so many people to be taking actions to avoid it. Is it that difficult to verify the headers? What technical problems are at issue here? > At 11:32 AM 8/24/2001 -0400, Dale Newfield wrote: > > >I've got another fairly simple idea that I figured I'd throw out for > >comment. I was about to send a note to an announcement list I run, and > >thought "hey, I should also send this to Bob." Problem is, if I CC or BCC > >Bob, he gets the mail I send to Mailman rather than the mail that Mailman > >would send out (with the subscription info/footer/etc.) What would be > >cool is if there were a way to List-BCC: people instead of BCC:'ing them. > >Then Mailman would be the one to distribute extra copies, and they could > >be the same as messages seen by list-subscribers. > > Maybe I'm missing something but this sounds like a setup for a spam relay. > > - Ben From benwa@ocentrix.com Mon Aug 27 18:20:27 2001 From: benwa@ocentrix.com (Ben Burnett) Date: Mon, 27 Aug 2001 10:20:27 -0700 Subject: [Mailman-Developers] Preventing spam to list admins. In-Reply-To: Message-ID: <5.1.0.14.0.20010827100427.00a58820@mail.ocentrix.com> At 09:27 AM 8/27/2001 -0700, Chuq Von Rospach wrote: >This has to be fixed in 2.1, if not before. I think the answer is to hide >the e-mail addresses in some way, probably by having a mail-to-the-admin >CGI, where only the admin's NAME is accessible publically, and Mailman >handles forwarding mail to them. I like this solution as long as whatever magic is done in the background is as short a path as possible. I can just see some part of Mailman breaking that this function is dependant upon, and no one can contact their list admin to let them know. - Ben From Dan Mick Mon Aug 27 18:36:44 2001 From: Dan Mick (Dan Mick) Date: Mon, 27 Aug 2001 10:36:44 -0700 (PDT) Subject: [Mailman-Developers] Preventing spam to list admins. Message-ID: <200108271736.KAA21242@utopia.West.Sun.COM> Why is this not handleable with a simple alias? Put "list-owner-name" there instead of "real-name", and Procmail list-owner-name. Surely one can't run an email service without *some* email admin talkback place, so....isn't the only answer abstraction and throttling through the abstraction? > I have a feeling I'm opening up another can of worms for Barry, but... > > Had an interesting issue with a list admin this morning. One of his user had > started getting spam, and because of various coincidences, thought it was > because our subscriber list had leaked. I did a little snooping, and found > that his address had been put on a public web page (not one of mine), and > showed him that it was likely harvested there. > > At which point, the admin of the list involved wrote and asked how to get > his address off of the info page for the lists he admins. After all, if you > go to .../mailman/listinfo/listname, down at the bottom, the admin addresses > are out there for all to see (and harvest). > > And -- I don't have an answer for that. > > But -- it's a legitimate problem. You can't exactly hide those pages behind > a security realm. As Mailman is structured, you can't really remove them, > and there's no way to protect them. > > But they need to be, because those pages are wide open, and accessible to > all the spiders, so they're going to leak into the global search engines, or > be harvested directly. > > Ugh. > > This has to be fixed in 2.1, if not before. I think the answer is to hide > the e-mail addresses in some way, probably by having a mail-to-the-admin > CGI, where only the admin's NAME is accessible publically, and Mailman > handles forwarding mail to them. > > In retrospect, this problem is painfully obvious to me, but personally, I'm > simply numb to having my e-mail address harvestable. But I think, in > general, it's a bad idea to put any e-mail address on a page, and I think > you can't programmatically obfuscate stuff, either (it'll be interesting to > see whether slashdot's new random-obfuscate system actually works, or > whether the harvesters will simply be able to figure out how it's obfuscated > and eat the addresses anyway... I'm not hopeful) > > What do others think? Anyone got any quick ideas on how to dela with this, > and what we ought to do long term? > > > -- > Chuq Von Rospach, Internet Gnome > [ = = ] > Yes, yes, I've finally finished my home page. Lucky you. > > USENET is a lot better after two or three eggnogs. We shouldn't allow > anyone on the net without a bottle of brandy. (chuq von rospach, 1992) > > > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers From chuqui@plaidworks.com Mon Aug 27 18:37:43 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 27 Aug 2001 10:37:43 -0700 Subject: [Mailman-Developers] Preventing spam to list admins. In-Reply-To: <200108271736.KAA21242@utopia.West.Sun.COM> Message-ID: On 8/27/01 10:36 AM, "Dan Mick" wrote: > Why is this not handleable with a simple alias? Put "list-owner-name" > there instead of "real-name", and Procmail list-owner-name. Because then the alias gets the spam, but then it still ends up in the admin's mailbox.... It doesn't solve the problem. -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. I'm out of my mind, but feel free to leave a message... From jra@baylink.com Mon Aug 27 18:39:35 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Mon, 27 Aug 2001 13:39:35 -0400 Subject: [Mailman-Developers] Preventing spam to list admins. In-Reply-To: ; from Chuq Von Rospach on Mon, Aug 27, 2001 at 09:27:30AM -0700 References: Message-ID: <20010827133935.47122@scfn.thpl.lib.fl.us> On Mon, Aug 27, 2001 at 09:27:30AM -0700, Chuq Von Rospach wrote: > What do others think? Anyone got any quick ideas on how to dela with this, > and what we ought to do long term? We ought to hunt down spammers who address harvest, and string them up. I am *not* kidding. 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 804 5015 "So easy to use, no wonder the Internet is going to hell!" -- me From chuqui@plaidworks.com Mon Aug 27 18:47:39 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 27 Aug 2001 10:47:39 -0700 Subject: [Mailman-Developers] Preventing spam to list admins. In-Reply-To: <20010827133935.47122@scfn.thpl.lib.fl.us> Message-ID: On 8/27/01 10:39 AM, "Jay R. Ashworth" wrote: > We ought to hunt down spammers who address harvest, and string them up. > > I am *not* kidding. As someone down the hall just said to me... "there are not enough bullets" Worse -- much as we find this stuff disgusting and want to shoot these people, we can't assume it's actualy illegal to do so. And it's an interesting question; even if it's illegal where you are, what does that mean to someone in, oh, Taiwan. Or Malaysia? So -- while at one level you're correct, in practice, we need a solution that deals with the problem now. And that means building walls with a gate, and a nice, burly guard making sure they check the ID before opening the door, because if we wait for the war to be outlawed and the army to be disbanded, we'll die of old age (and do so as a serf of the other side...) -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. Yes, I am an agent of Satan, but my duties are largely ceremonial. From claw@kanga.nu Mon Aug 27 19:23:35 2001 From: claw@kanga.nu (J C Lawrence) Date: Mon, 27 Aug 2001 11:23:35 -0700 Subject: [Mailman-Developers] Preventing spam to list admins. In-Reply-To: Message from Chuq Von Rospach of "Mon, 27 Aug 2001 09:27:30 PDT." References: Message-ID: <1957.998936615@kanga.nu> On Mon, 27 Aug 2001 09:27:30 -0700 Chuq Von Rospach wrote: > But -- it's a legitimate problem. You can't exactly hide those > pages behind a security realm. As Mailman is structured, you can't > really remove them, and there's no way to protect them. I would argue conversely that listname-owner@domain needs to be publicly known and accessable in the same way that postmaster@domain is. The fact that postmaster is now often used as an alias for /dev/null is unfortunate, but seems to be part of the territory. > This has to be fixed in 2.1, if not before. I think the answer is > to hide the e-mail addresses in some way, probably by having a > mail-to-the-admin CGI, where only the admin's NAME is accessible > publically, and Mailman handles forwarding mail to them. > In retrospect, this problem is painfully obvious to me, but > personally, I'm simply numb to having my e-mail address > harvestable. But I think, in general, it's a bad idea to put any > e-mail address on a page, and I think you can't programmatically > obfuscate stuff, either (it'll be interesting to see whether > slashdot's new random-obfuscate system actually works, or whether > the harvesters will simply be able to figure out how it's > obfuscated and eat the addresses anyway... I'm not hopeful) I'd go two fold: Leave it exactly as-is as the default. Allow the HTML footers that are currently placed on the bottom of the list pages to be editable such that on a per-site/list basis, if needed/wanted you could remove them, point them to something else, etc. Sure, adding a web form blinder to Mailman might be nice as an optional feature, but in a great many circumstances that address needed to be exposed (and should be). We shouldn't mandate the CGI. The cheap approach is allow for edits and substitutions and then later perhaps add some of those substitutions in as optional features. -- J C Lawrence )\._.,--....,'``. ---------(*) /, _.. \ _\ ;`._ ,. claw@kanga.nu `._.-(,_..'--(,_..'`-.;.' http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly From claw@kanga.nu Mon Aug 27 19:30:37 2001 From: claw@kanga.nu (J C Lawrence) Date: Mon, 27 Aug 2001 11:30:37 -0700 Subject: [Mailman-Developers] Preventing spam to list admins. In-Reply-To: Message from Chuq Von Rospach of "Mon, 27 Aug 2001 10:47:39 PDT." References: Message-ID: <2066.998937037@kanga.nu> On Mon, 27 Aug 2001 10:47:39 -0700 Chuq Von Rospach wrote: > Worse -- much as we find this stuff disgusting and want to shoot > these people, we can't assume it's actualy illegal to do so. And > it's an interesting question; even if it's illegal where you are, > what does that mean to someone in, oh, Taiwan. Or Malaysia? > So -- while at one level you're correct, in practice, we need a > solution that deals with the problem now. And that means building > walls with a gate, and a nice, burly guard making sure they check > the ID before opening the door, because if we wait for the war to > be outlawed and the army to be disbanded, we'll die of old age > (and do so as a serf of the other side...) If you aren't doing it now, start praying and agitating for widespread deployment of IPv6. Why? Because with IPv6 comes widespread PKI infrastructures, and with that the major thing that's holding back SMTP/TLS (other than admin intransigence). If each MTA would stamp a TLS-based hash in its received line which can be auth'ed against that domain's certificate.... From there let human nature take over. -- J C Lawrence )\._.,--....,'``. ---------(*) /, _.. \ _\ ;`._ ,. claw@kanga.nu `._.-(,_..'--(,_..'`-.;.' http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly From chuqui@plaidworks.com Mon Aug 27 22:02:54 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 27 Aug 2001 14:02:54 -0700 Subject: [Mailman-Developers] Preventing spam to list admins. In-Reply-To: <1957.998936615@kanga.nu> Message-ID: On 8/27/01 11:23 AM, "J C Lawrence" wrote: > On Mon, 27 Aug 2001 09:27:30 -0700 > Chuq Von Rospach wrote: > >> But -- it's a legitimate problem. You can't exactly hide those >> pages behind a security realm. As Mailman is structured, you can't >> really remove them, and there's no way to protect them. > > I would argue conversely that listname-owner@domain needs to be > publicly known and accessable in the same way that postmaster@domain > is. The fact that postmaster is now often used as an alias for > /dev/null is unfortunate, but seems to be part of the territory. I don't disagree -- but that's not the address on the listinfo pages, either. And that's ANOTHER problem to deal with, now that you mention it. I think what this implies is that mailman ought to have all incoming mail proccessed through the same anti-spam rejection filters that it uses for posting e-mail (especially since we plan on upgrading that in 2.1 for better scripting and auto-reject, right?). So maybe the listinfo pages report the admin addresses as Chuq Von rospach , and that goes through some kind of filter. But -- I still don't like that option a huge amount, since it requires an admin to manually work to staunch the flow of spam. Mailman needs to do what it can to keep addresses out of the spam harvesters grasp in the first place, to the greatest extent possible -- both subscribers AND admins. I dunno that there's a damn thing we can do about the hardwired addresses, but I don't think that also gives us the right to take someone's email address and stuff it on a web page without an attempt to protect it. Some of us have taken great pains to protect those addresses in the archives from harvesters. I'm quite chagrined to realize I've been doing it happily to the admins at the same time. > Sure, adding a web form blinder to Mailman might be nice as an > optional feature, but in a great many circumstances that address > needed to be exposed (and should be). We shouldn't mandate the CGI. > The cheap approach is allow for edits and substitutions and then > later perhaps add some of those substitutions in as optional > features. I think we DO need to mandate the CGI for SOME addresses. But we can discuss what addresses should be stuck behind the garrison, and what addresses can't be, and for those, see what armor we can give them in other ways. I don't think we can do nothing, and I don't think the answer is "have them filter with procmail" -- mailman is creating this problem, and not only doesn't everyone have access to tools like procmail (or the interest in hacking it), it's a problem created by mailman, and I don't think the program should shirk it's responsibility onto the admin or some other tool. The less we deal with this RIGHT, the more we contribute to things like postmaster=>/dev/null issues..... -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. Shroedinger: We can never really be sure which side of the road the chicken is on. It's all a matter of chance. Like a game of dice. Einstein, refuting Schroedinger: God does not play dice with chickens. Heisenburg: We can determine how fast the chicken travelled, or where it ended up, but we cannot determine why it did so. From donal.hunt2@mail.dcu.ie Tue Aug 28 00:36:56 2001 From: donal.hunt2@mail.dcu.ie (donal.hunt2@mail.dcu.ie) Date: Tue, 28 Aug 2001 00:36:56 +0100 Subject: [Mailman-Developers] =?iso-8859-1?Q?handle=5Fopts=2Epy?= Message-ID: <3B691C6A000063DB@hawk.dcu.ie> Hi there, I'm currently messing about with adding some LDAP functionality to mailma= n and need a kick in the right direction. I'm working with Mailman-2.0.2 (don't ask!!), and have modified handle_op= ts.py to not mail out a password if the user is stored in LDAP (this is if the user clicks the "email me my password" button on the subscription page). I've tried to compile the code so that I get a handle_opts binary, but everytime i compile it the added functionality doesn't appear. I'm compiling by doing a make in the mailman-2.0.2 folder (ie the root of= the source) and the binary ends up in mailman-2.0.2/src. i'm *not* doing a make install - don't want the installation overwritten just yet! Is there a quicker and easier way to recompile the handle_opts binary and= any ideas why the functionality i'm adding isn't appearing after compilat= ion... Know you're probably real busy with the 2.1 alpha Barry, so i'm cc-ing to= the list too. Thanks in advance Donal From claw@kanga.nu Tue Aug 28 06:14:12 2001 From: claw@kanga.nu (J C Lawrence) Date: Mon, 27 Aug 2001 22:14:12 -0700 Subject: [Mailman-Developers] Preventing spam to list admins. In-Reply-To: Message from Chuq Von Rospach of "Mon, 27 Aug 2001 14:02:54 PDT." References: Message-ID: <8366.998975652@kanga.nu> On Mon, 27 Aug 2001 14:02:54 -0700 Chuq Von Rospach wrote: > On 8/27/01 11:23 AM, "J C Lawrence" wrote: >> On Mon, 27 Aug 2001 09:27:30 -0700 Chuq Von Rospach >> wrote: >>> But -- it's a legitimate problem. You can't exactly hide those >>> pages behind a security realm. As Mailman is structured, you >>> can't really remove them, and there's no way to protect them. >> I would argue conversely that listname-owner@domain needs to be >> publicly known and accessable in the same way that >> postmaster@domain is. The fact that postmaster is now often used >> as an alias for /dev/null is unfortunate, but seems to be part of >> the territory. > I don't disagree -- but that's not the address on the listinfo > pages, either. And that's ANOTHER problem to deal with, now that > you mention it. Aye, that's a long term niggle for me: The admins on the listinfo pages et al should be reported as listname-admin@domain, not the actual addresses. > I think what this implies is that mailman ought to have all > incoming mail proccessed through the same anti-spam rejection > filters that it uses for posting e-mail (especially since we plan > on upgrading that in 2.1 for better scripting and auto-reject, > right?). So maybe the listinfo pages report the admin addresses as > Chuq Von rospach , and that goes through > some kind of filter. Which tends to break on those site which use gang moderation. Actually some of the more interesting cases are where the admin address for a list is actually another list. This form is commonly used for IS depts and the lists they manage for their company. > But -- I still don't like that option a huge amount, since it > requires an admin to manually work to staunch the flow of > spam. Mailman needs to do what it can to keep addresses out of the > spam harvesters grasp in the first place, to the greatest extent > possible -- both subscribers AND admins. There are two conflicting requirements here: 1) The list admin address needs to be cannonical, well known, and always supported. 2) We can't tell anybody about it. #2 just doesn't work. What we can do is try and institute methods for sites to help them control the damage wreaked by #1. Sadly, I don't have a lot of suggestions there. other than the fact that doing away with #1 is not an acceptable answer. > I dunno that there's a damn thing we can do about the hardwired > addresses, but I don't think that also gives us the right to take > someone's email address and stuff it on a web page without an > attempt to protect it. >> Sure, adding a web form blinder to Mailman might be nice as an >> optional feature, but in a great many circumstances that address >> needed to be exposed (and should be). We shouldn't mandate the >> CGI. The cheap approach is allow for edits and substitutions and >> then later perhaps add some of those substitutions in as optional >> features. > I think we DO need to mandate the CGI for SOME addresses. I think we can mandate Mailman specific processing for *SOME* addresses, ala SPAM filters, but mandating that they can only be accessed via a web CGI versus SMTP mail is posit is fundamentally wrong. > But we can discuss what addresses should be stuck behind the > garrison, and what addresses can't be, and for those, see what > armor we can give them in other ways. I don't think we can do > nothing, and I don't think the answer is "have them filter with > procmail"... Well, of course we can. Many do precisely this (little). Its just that we'd do better and be better if we didn't. Its more admirable to step up to the plate, even if you do miss the ball. -- J C Lawrence )\._.,--....,'``. ---------(*) /, _.. \ _\ ;`._ ,. claw@kanga.nu `._.-(,_..'--(,_..'`-.;.' http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly From chuqui@plaidworks.com Tue Aug 28 06:56:32 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 27 Aug 2001 22:56:32 -0700 Subject: [Mailman-Developers] Preventing spam to list admins. In-Reply-To: <8366.998975652@kanga.nu> Message-ID: On 8/27/01 10:14 PM, "J C Lawrence" wrote: >> I don't disagree -- but that's not the address on the listinfo >> pages, either. And that's ANOTHER problem to deal with, now that >> you mention it. > > Aye, that's a long term niggle for me: The admins on the listinfo > pages et al should be reported as listname-admin@domain, not the > actual addresses. One thing I've been mulling over today is whether we're being too paranoid here. We DO know that spambots will harvest addresses it finds on web pages. So those web pages need to be protected, obscured, or the addresses kept off of them. We DO know standard addresses (postmaster, webmaster, etc et al) and mailing list posting addresses get harvested by spambots and added to their lists. But do we know of spambots that say "because list@foo.com exists, we should also spam list-owner@foo.com"? I don't think that happens, and so I'm wondering if we try to protect this "standard" address we may be solving a problem that doesn't (and isn't likely to) exist. I like the idea of having mail funnel through listname-owner@domain, and have that point to the list of all admins (or with 2.1, where we have list admins, content admins and site admins, how weill this breakout change? Hmm). Seems to me the answer is to bridge access to that address through some kind of interface that spambots can't traverse, but humans can. That would mean not putting mailtos on the page, but doing something that would let the user mail the admin. I'm not necessarily a fan of the "send email" form thing, either, since if mailman breaks, that form also probably breaks (and how will they email us to tell us It's broken?), but I'm not sure there's are many alternatives that solve all of these problems... I do believe that shifting the listinfo page to be a mailto to the -owner address will only get that address on the spam lists and solve nothing.... I'm still thinknig my way through this. There are going to be a tradeoffs here... > There are two conflicting requirements here: > > 1) The list admin address needs to be cannonical, well known, and > always supported. > > 2) We can't tell anybody about it. Does it have to be well-known? Canonical? Or is it something that simply has to be available on request? There ARE addresses that have to be canonical and well-known, but are list-admin addresses one of those? Or can we, say, generate them dynamically or simply hide them through some accessible interface? I'm not promoting these as solutions. I'm wondering if they might be solutions. > What we can do is try and institute methods for sites to help them > control the damage wreaked by #1. Sadly, I don't have a lot of > suggestions there. other than the fact that doing away with #1 is > not an acceptable answer. The first answer is to run it all through whatever mailman uses for anti-spam for the posting addresses. Which would at least allow us to define auto-bounce rules for the "easy" stuff, like pr0n, judicial judgements and the like. We could filter out the "low hanging fruit" with a decent tool, if it filters admin mail through it. But that's only low hanging fruit. And a partial solution. But it's a start. >> armor we can give them in other ways. I don't think we can do >> nothing, and I don't think the answer is "have them filter with >> procmail"... > > Well, of course we can. Many do precisely this (little). Its just > that we'd do better and be better if we didn't. Its more admirable > to step up to the plate, even if you do miss the ball. Or foul it off. Tell your admins running lists from AOL that all they need to do is install procmail... No, I think if we create a problem (and we are) we have some responsibility to minimize it and do what we can about it. It might not be easy for Mailman developers, but then, by the same rationale, we could do away with subscription validation, no? -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. 95% of being a net.god is sounding persuasive and convincing people you know what you're talking about, even when you're making it up as you go along. (chuq von rospach, 1992) From claw@kanga.nu Tue Aug 28 07:33:43 2001 From: claw@kanga.nu (J C Lawrence) Date: Mon, 27 Aug 2001 23:33:43 -0700 Subject: [Mailman-Developers] Preventing spam to list admins. In-Reply-To: Message from Chuq Von Rospach of "Mon, 27 Aug 2001 22:56:32 PDT." References: Message-ID: <9128.998980423@kanga.nu> On Mon, 27 Aug 2001 22:56:32 -0700 Chuq Von Rospach wrote: > On 8/27/01 10:14 PM, "J C Lawrence" wrote: > I like the idea of having mail funnel through > listname-owner@domain, and have that point to the list of all > admins (or with 2.1, where we have list admins, content admins and > site admins, how weill this breakout change? Hmm). Seems to me > the answer is to bridge access to that address through some kind > of interface that spambots can't traverse, but humans can. That > would mean not putting mailtos on the page, but doing something > that would let the user mail the admin. I'm not necessarily a fan > of the "send email" form thing, either, since if mailman breaks, > that form also probably breaks (and how will they email us to tell > us It's broken?), but I'm not sure there's are many alternatives > that solve all of these problems... Okay, have the text on the page read listname-admin@domain, but have the link invoke a CGI which presents a form to write/send a message. > I do believe that shifting the listinfo page to be a mailto to the > -owner address will only get that address on the spam lists and > solve nothing.... I don't know that that problem is, or should be, resolvable. Humans need to see/get that address. That means that harvesters can too. >> There are two conflicting requirements here: >> >> 1) The list admin address needs to be cannonical, well known, and >> always supported. >> >> 2) We can't tell anybody about it. > Does it have to be well-known? Canonical? Yes, and yes. Users will know and learn the pattern, will expect it, and will use it (they do already). This is a Good Thing. > Or is it something that simply has to be available on request? Won't work if Mailman is down. The admin-address is specifically needed be direct. > There ARE addresses that have to be canonical and well-known, but > are list-admin addresses one of those? Or can we, say, generate > them dynamically or simply hide them through some accessible > interface? I don't believe so. >> What we can do is try and institute methods for sites to help >> them control the damage wreaked by #1. Sadly, I don't have a lot >> of suggestions there. other than the fact that doing away with #1 >> is not an acceptable answer. > The first answer is to run it all through whatever mailman uses > for anti-spam for the posting addresses. Which would at least > allow us to define auto-bounce rules for the "easy" stuff, like > pr0n, judicial judgements and the like. We could filter out the > "low hanging fruit" with a decent tool, if it filters admin mail > through it. > But that's only low hanging fruit. And a partial solution. But > it's a start. I'm leery of trying to do too much. We don't need to. If we do just enough and make it easy for others to follow, they can and will do the rest. We can then cherry pick. >>> armor we can give them in other ways. I don't think we can do >>> nothing, and I don't think the answer is "have them filter with >>> procmail"... >> Well, of course we can. Many do precisely this (little). Its >> just that we'd do better and be better if we didn't. Its more >> admirable to step up to the plate, even if you do miss the ball. > Or foul it off. Tell your admins running lists from AOL that all > they need to do is install procmail... > No, I think if we create a problem (and we are) we have some > responsibility to minimize it and do what we can about it. It > might not be easy for Mailman developers, but then, by the same > rationale, we could do away with subscription validation, no? You misunderstand. I'm agreeing with you above. -- J C Lawrence )\._.,--....,'``. ---------(*) /, _.. \ _\ ;`._ ,. claw@kanga.nu `._.-(,_..'--(,_..'`-.;.' http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly From che@debian.org Tue Aug 28 07:45:49 2001 From: che@debian.org (Ben Gertzfield) Date: Tue, 28 Aug 2001 15:45:49 +0900 Subject: [Mailman-Developers] [PATCH] Modifying #! env python line to match --with-python Message-ID: <87itf88yxu.fsf@nausicaa.interq.or.jp> Many, many utility programs and other scripts that are in Mailman CVS have #! /usr/bin/env python hard-coded in them, and do not use the @PYTHON@ symbol exported from autoconf. This means that the --with-python flag cannot be ever used if python is not named "python"; for Debian Linux, this is a Big Problem, because the python 1.6 and python 2.0 binaries have different names. (/usr/bin/python vs /usr/bin/python2). So, I created a patch that makes building possible when python is called *anything*; I've tested it on Debian GNU/Linux unstable, where python is called python2, and it works. The patch (it's 500K, because it renames a lot of files) is available at: http://nausicaa.interq.or.jp/mailman/with-python.patch It does the following: 1) Defines a shell variable SCRIPTS in configure.in. This variable contains a list of scripts that are to be created from script.in templates; the only thing that we care about expanding is changing the first line, from: #! /usr/bin/env python to: #! /usr/bin/env @PYTHON@ This variable is passed in to AC_SUBST and AC_OUTPUT both, so that the top-level Makefile can do a 'rm -f ${SCRIPTS}' in its make distclean target. 2) Renames all the scripts that used the hard-coded name for python from (for example) bin/qrunner to bin/qrunner.in 3) Chmods 0755 all the generated scripts from the top-level Makefile, by adding a 'script-perms' target to the 'all' target. 4) Removes misc/mailman on a make distclean (this was auto-generated before but never removed on a make distclean, probably messed up some people's patches..) by editing misc/Makefile.in. This is totally unrelated to the other fixes but it's pretty obviously a minor bug. It would be trivial to move the SCRIPTS variable definition to a file outside of configure.in, if that's a cleaner way to maintain it in the future. There are some files in the Mailman CVS tree that have #! /usr/bin/env python lines, but are never really executed. I didn't munge these files, because forcing folks to guess that SOME files in the Mailman source tree are .in and others aren't is icky These files are: [ben@nausicaa:~/src/mailman/mailman]% find . -type f -print0 | xargs -0 grep -H '#!.*env.*python' ./Mailman/Post.py:#! /usr/bin/env python ./Mailman/Archiver/pipermail.py:#! /usr/bin/env python ./misc/Cookie.py:#!/usr/bin/env python If I'm wrong, and these should be included in the SCRIPTS variable, feel free to change the patch. But I excluded them for now. Here's the list of files I did include in the SCRIPTS variable. These are the ones that are renamed to (for example) contrib/rotatelogs.py.in by the patch and changed to use #! /usr/bin/env @PYTHON@ . contrib/rotatelogs.py contrib/qmail-to-mailman.py contrib/securelinux_fix.py filters/bowa-strip Mailman/pythonlib/mailbox.py cron/senddigests cron/bumpdigests cron/nightly_gzip cron/mailpasswds cron/gate_news cron/checkdbs admin/bin/Release.py admin/bin/mm2do admin/bin/faq2ht.py bin/update bin/newlist bin/check_perms bin/find_member bin/withlist bin/mailmanctl bin/change_pw bin/list_admins bin/check_db bin/list_lists bin/pygettext.py bin/qrunner bin/clone_member bin/genaliases bin/digest_arch bin/arch bin/rmlist bin/mmsitepass bin/version bin/remove_members bin/config_list bin/list_members bin/sync_members bin/add_members bin/dumpdb scripts/mailowner scripts/mailcmd scripts/post scripts/leave scripts/join scripts/auto src/setup.py Please let me know if there are any comments/suggestions. Now that I've got mailman building on Debian unstable, I can start testing the patch I made for avoiding duplicate mails. *grin* Ben -- Brought to you by the letters P and C and the number 1. "Ohhhh, Mentos Boy!" Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From che@debian.org Tue Aug 28 12:43:17 2001 From: che@debian.org (Ben Gertzfield) Date: Tue, 28 Aug 2001 20:43:17 +0900 Subject: [Mailman-Developers] [PATCH] CVS typo fix: Let users actually set options Message-ID: <87ae0k5s16.fsf@nausicaa.interq.or.jp> Big oops in the CVS, Barry! I was struggling to understand why, with my new code to let users avoid duplicate messages, I couldn't get the options for any user to change.. turns out there was a silly typo in Mailman/OldStyleMemberships.py which had been preventing all users from EVER setting any options in CVS Mailman. Patch follows, and is pretty self-evident when you look at it. --- mailman.cvs.orig/Mailman/OldStyleMemberships.py Thu Aug 16 15:32:11 2001 +++ mailman/Mailman/OldStyleMemberships.py Tue Aug 28 20:38:47 2001 @@ -273,9 +273,9 @@ # the entry below just to make things (questionably) cleaner. flags = self.__mlist.user_options.setdefault(memberkey, 0) if value: - self.__mlist.user_options[memberkey] |= flags + self.__mlist.user_options[memberkey] |= flag else: - self.__mlist.user_options[memberkey] &= ~flags + self.__mlist.user_options[memberkey] &= ~flag if not self.__mlist.user_options[memberkey]: del self.__mlist.user_options[memberkey] Ben -- Brought to you by the letters D and M and the number 12. "If you turn both processors off, you will have to reboot." Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From che@debian.org Tue Aug 28 14:37:37 2001 From: che@debian.org (Ben Gertzfield) Date: Tue, 28 Aug 2001 22:37:37 +0900 Subject: [Mailman-Developers] [PATCH] Duplicate mail avoiding in Mailman Message-ID: <87lmk42tlq.fsf@nausicaa.interq.or.jp> Finally! Here's the patch to avoid sending out list duplicates to users who don't want it. This is a solution to the never-ending feuding on various Debian mailing lists about whether or not people should Cc: folks already on the list; hopefully, this user-configurable behavior will make everyone's lives easier. This patch is against mailman CVS. The patch adds a DontReceiveDuplicates flag to mm_cfg (value 128). By default, this is 0, which is the same as our current behavior. If DontReceiveDuplicates is set to 1 for the user, then they will not receive a list message if: 1) the qrunner process has already set a mail with that message-id to that user -or- 2) the user is specifically listed in the To:, Cc:, Resent-To:, or Resent-Cc: fields. If DontReceiveDuplicates is set to 0 and Personalization is enabled for the list, a X-Mailman-Duplicate: yes will be added to every duplicate message sent out (not the first) to allow users to filter for themselves. I have not done any i18n for this code, mea culpa. But the option is settable via the web interface or the mail interface. (it's the "nodupes" option via mail.) Issues: 1) What happens if people fake their Message-IDs? It's possible (but hard) to stop real list mail from coming through to someone who doesn't get duplicates, if you send out lots of messages with the same Message-ID. 2) Does this use a lot of memory? I'm using a two-level hash to store the message IDs and email addresses that have been seen; I don't know if this will grow huge on big sites. 3) Is there any way to add the X-Mailman-Duplicate: yes header to various users when the admin is not using Personalization on the lists? 4) If multiple qrunner processes end up handling mails, it's possible a user who doesn't want duplicates will get them. How can we fix this? 5) Some users probably don't want list duplicates if the message is addressed to multiple lists that they belong to, but DO want duplicates if they're specifically listed in To:/Cc:/etc. Should we make yet another option for this? Please, comments are definitely appreciated. The patch works for me, as long as the previous patch I sent to the list (allowing users to actually set options) is applied. This and my previous patches are all available at: http://nausicaa.interq.or.jp/mailman/ Patch follows. diff -x CVS -x messages -ruN mailman.orig/Mailman/Cgi/options.py mailman/Mailman/Cgi/options.py --- mailman.orig/Mailman/Cgi/options.py Thu Aug 2 13:14:43 2001 +++ mailman/Mailman/Cgi/options.py Tue Aug 28 22:10:21 2001 @@ -375,6 +375,7 @@ ('conceal', mm_cfg.ConcealSubscription), ('remind', mm_cfg.SuppressPasswordReminder), ('rcvtopic', mm_cfg.ReceiveNonmatchingTopics), + ('nodupes', mm_cfg.DontReceiveDuplicates), ): try: newval = int(cgidata.getvalue(item)) @@ -449,9 +450,18 @@ global_remind = newval break - if global_enable is not None or global_remind is not None: + global_nodupes = None + if cgidata.getvalue('nodupes-globally'): + for flag, newval in newvals: + if flag == mm_cfg.DontReceiveDuplicates: + global_nodupes = newval + break + + if (global_enable is not None or global_remind is not None + or global_nodupes is not None): for gmlist in lists_of_member(mlist.host_name, user): - global_options(gmlist, user, global_enable, global_remind) + global_options(gmlist, user, global_enable, global_remind, + global_nodupes) # Now print the results if cantdigest: @@ -526,6 +536,10 @@ mlist.FormatOptionButton(mm_cfg.ConcealSubscription, 0, user)) replacements[''] = mlist.FormatOptionButton( mm_cfg.ConcealSubscription, 1, user) + replacements[''] = ( + mlist.FormatOptionButton(mm_cfg.DontReceiveDuplicates, 1, user)) + replacements[''] = ( + mlist.FormatOptionButton(mm_cfg.DontReceiveDuplicates, 0, user)) replacements[''] = ( mlist.FormatButton('unsub', _('Unsubscribe')) + '
' + CheckBox('unsubconfirm', 1, checked=0).Format() + @@ -555,6 +569,8 @@ CheckBox('deliver-globally', 1, checked=0).Format()) replacements[''] = ( CheckBox('remind-globally', 1, checked=0).Format()) + replacements[''] = ( + CheckBox('nodupes-globally', 1, checked=0).Format()) days = int(mm_cfg.PENDING_REQUEST_LIFE / mm_cfg.days(1)) if days > 1: @@ -741,7 +757,7 @@ -def global_options(mlist, user, global_enable, global_remind): +def global_options(mlist, user, global_enable, global_remind, global_nodupes): def sigterm_handler(signum, frame, mlist=mlist): # Make sure the list gets unlocked... mlist.Unlock() @@ -762,6 +778,10 @@ if global_remind is not None: mlist.setMemberOption(user, mm_cfg.SuppressPasswordReminder, global_remind) + + if global_nodupes is not None: + mlist.setMemberOption(user, mm_cfg.DontReceiveDuplicates, + global_nodupes) mlist.Save() finally: diff -x CVS -x messages -ruN mailman.orig/Mailman/Defaults.py.in mailman/Mailman/Defaults.py.in --- mailman.orig/Mailman/Defaults.py.in Tue Aug 21 00:04:21 2001 +++ mailman/Mailman/Defaults.py.in Tue Aug 28 21:15:10 2001 @@ -269,6 +269,7 @@ 'Hold', 'Tagger', 'CalcRecips', + 'AvoidDuplicates', 'Cleanse', 'CookHeaders', 'ToDigest', @@ -722,6 +723,7 @@ ConcealSubscription = 16 SuppressPasswordReminder = 32 ReceiveNonmatchingTopics = 64 +DontReceiveDuplicates = 128 # Authentication contexts. # diff -x CVS -x messages -ruN mailman.orig/Mailman/HTMLFormatter.py mailman/Mailman/HTMLFormatter.py --- mailman.orig/Mailman/HTMLFormatter.py Sat Aug 18 06:18:43 2001 +++ mailman/Mailman/HTMLFormatter.py Tue Aug 28 21:15:31 2001 @@ -117,6 +117,7 @@ mm_cfg.ConcealSubscription : 'conceal', mm_cfg.SuppressPasswordReminder : 'remind', mm_cfg.ReceiveNonmatchingTopics : 'rcvtopic', + mm_cfg.DontReceiveDuplicates : 'nodupes', }[type] return '' % ( name, value, checked) diff -x CVS -x messages -ruN mailman.orig/Mailman/Handlers/AvoidDuplicates.py mailman/Mailman/Handlers/AvoidDuplicates.py --- mailman.orig/Mailman/Handlers/AvoidDuplicates.py Thu Jan 1 09:00:00 1970 +++ mailman/Mailman/Handlers/AvoidDuplicates.py Tue Aug 28 22:17:46 2001 @@ -0,0 +1,118 @@ +# Copyright (C) 1998,1999,2000,2001 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. + +"""If the user wishes it, do not send duplicates of the same message. + +This module keeps an in-memory dictionary of Message-ID and recipient +pairs. If a message with an identical Message-ID is about to be sent +to someone who has already received a copy, we either drop the message, +add a duplicate warning header, or pass it through, depending on the +user's preferences. +""" + +import string + +from Mailman import mm_cfg +from Mailman import Utils +from Mailman import Message +from Mailman import Errors +from Mailman.i18n import _ +from mimelib.address import getaddresses + + + +class DuplicateDetected(Errors.DiscardMessage): + """The message would have been sent multiple times to a user who + prefers not to receive duplicates.""" + +# A dictionary of dictionaries, used to store which recipients have received +# which message IDs. +recip_msgids = {} + + + +def process(mlist, msg, msgdata): + + recips = msgdata['recips'] + msgid = msg.get('message-id') + + if not recips or not msgid: + return + + # This dictionary will hold recips who want their mail to have + # the X-Mailman-Duplicate: yes header. + if not msgdata.has_key('add-dupe-header'): + msgdata['add-dupe-header'] = {} + + # Happily borrowed from mimelib.getaddresses() example + tos = msg.getall('to') + ccs = msg.getall('cc') + resent_tos = msg.getall('resent-to') + resent_ccs = msg.getall('resent-cc') + external_recips = getaddresses(tos + ccs + resent_tos + resent_ccs) + + # Anyone mentioned in the to/cc/resent-to/resent-cc headers should + # not get a duplicate of the message. + for (name, email) in external_recips: + + # If getaddresses fails, email could be null. Skip those. + if not email: + continue + + # Initialize the external recipient's msgid hash if this is the + # first email they've received with this message-id. + if not recip_msgids.has_key(email): + recip_msgids[email] = {} + + # We don't do anything except record that that address has + # gotten or will get a copy of this email externally. + recip_msgids[email][msgid] = 1 + + newrecips = [] + + for r in recips: + if not recip_msgids.has_key(r): + recip_msgids[r] = {} + + # If they have received a message with this message-id already, + # see if they don't want duplicates. + if recip_msgids[r].has_key(msgid): + send_duplicate = 1 + + # If the member wants to receive duplicates, or if the recipient + # is not a member at all, just flag the X-Mailman-Duplicate: yes + # header. + try: + if mlist.getMemberOption(r, mm_cfg.DontReceiveDuplicates): + send_duplicate = 0 + except Errors.NotAMemberError: + pass + + # We'll send a duplicate unless the user doesn't wish it. + # If personalization is enabled, the add-dupe-header flag will + # add a X-Mailman-Duplicate: yes header for this user's message. + if send_duplicate: + msgdata['add-dupe-header'][r] = 1 + newrecips.append(r) + + else: + # Otherwise, this is the first time they've been in the recips + # list. Add them to the newrecips list and flag them as having + # received this message. + recip_msgids[r][msgid] = 1 + newrecips.append(r) + + msgdata['recips'] = newrecips diff -x CVS -x messages -ruN mailman.orig/Mailman/Handlers/Personalize.py mailman/Mailman/Handlers/Personalize.py --- mailman.orig/Mailman/Handlers/Personalize.py Sat Aug 18 06:20:58 2001 +++ mailman/Mailman/Handlers/Personalize.py Tue Aug 28 21:10:17 2001 @@ -46,11 +46,23 @@ msg['To'] = '%s (%s)' % (member, name) else: msg['To'] = member + + # We can flag the mail as a duplicate for each member, if + # they've already received that message. (See AvoidDuplicates.py) + if msgdata['add-dupe-header'].has_key(member): + msg['X-Mailman-Duplicate'] = 'yes' + elif msg.has_key('X-Mailman-Duplicate'): + del msg['X-Mailman-Duplicate'] + inq.enqueue(msg, metadatacopy, listname=mlist.internal_name()) # Restore the original To: line del msg['To'] msg['To'] = originalto + + # The original message is not a duplicate. + if msg.has_key('X-Mailman-Duplicate'): + del msg['X-Mailman-Duplicate'] # Don't let the normal ToOutgoing processing actually send the original # copy. diff -x CVS -x messages -ruN mailman.orig/Mailman/MailCommandHandler.py mailman/Mailman/MailCommandHandler.py --- mailman.orig/Mailman/MailCommandHandler.py Fri Aug 17 14:37:15 2001 +++ mailman/Mailman/MailCommandHandler.py Tue Aug 28 21:19:44 2001 @@ -80,27 +80,36 @@ you get digests in MIME format, which are much better if you have a mail reader that supports MIME.""") -option_desc = {'hide' : HIDE, - 'nomail' : NOMAIL, - 'ack' : ACK, - 'notmetoo': NOTMETOO, - 'digest' : DIGEST, - 'plain' : PLAIN, +NODUPES = _("""When turned on, you do *not* receive duplicate mails if mail is +sent to multiple lists that you belong to. This option will let you avoid +duplicate mails; if you turn it on, you will never receive multiple copies +of the same message. Also, if you *and* the list are mentioned explicitly +in the To: or Cc: headers of a message, you will not receive duplicates if +this is turned on.""") + +option_desc = {'hide' : HIDE, + 'nomail' : NOMAIL, + 'ack' : ACK, + 'notmetoo' : NOTMETOO, + 'digest' : DIGEST, + 'plain' : PLAIN, + 'nodupes' : NODUPES, } # jcrey: and then the real one _ = Mailman.i18n._ -option_info = {'hide' : mm_cfg.ConcealSubscription, - 'nomail' : mm_cfg.DisableDelivery, - 'ack' : mm_cfg.AcknowledgePosts, - 'notmetoo': mm_cfg.DontReceiveOwnPosts, - 'digest' : 0, - 'plain' : mm_cfg.DisableMime, +option_info = {'hide' : mm_cfg.ConcealSubscription, + 'nomail' : mm_cfg.DisableDelivery, + 'ack' : mm_cfg.AcknowledgePosts, + 'notmetoo' : mm_cfg.DontReceiveOwnPosts, + 'digest' : 0, + 'plain' : mm_cfg.DisableMime, + 'nodupes' : mm_cfg.DontReceiveDuplicates } # ordered list -options = ('hide', 'nomail', 'ack', 'notmetoo', 'digest', 'plain') +options = ('hide', 'nomail', 'ack', 'notmetoo', 'digest', 'plain', 'nodupes') # strip just the outer layer of quotes quotecre = re.compile(r'["\'`](?P.*)["\'`]') diff -x CVS -x messages -ruN mailman.orig/templates/en/help.txt mailman/templates/en/help.txt --- mailman.orig/templates/en/help.txt Sat May 19 06:28:54 2001 +++ mailman/templates/en/help.txt Tue Aug 28 21:21:56 2001 @@ -79,6 +79,10 @@ Conceals your address when people look at who is on this list. + nodupes: + Turn this on if you do not want to receive duplicate mail + from the list, in case you are explicitly in the To: or Cc: + fields already or are included in multiple lists in one message. options Show the current values of your list options. diff -x CVS -x messages -ruN mailman.orig/templates/en/options.html mailman/templates/en/options.html --- mailman.orig/templates/en/options.html Thu Jul 19 06:54:40 2001 +++ mailman/templates/en/options.html Tue Aug 28 22:09:46 2001 @@ -280,6 +280,26 @@ Yes + + Avoid duplicate copies of messages?

+ + When you are listed explicitly in the To: or Cc: headers + of a list message, or a message is sent to multiple lists + that you are a member of, you can opt to not receive another + copy from the mailing list. Select Yes to avoid + receiving duplicate copies from the mailing list; select + No to receive duplicate copies. + +

If the list has per-message personalization + enabled, every duplicate mail will have a + X-Mailman-Duplicate: yes header added to it. + + + No
+ Yes

+ Set globally + +

-- Brought to you by the letters M and V and the number 8. "Hoosh is a kind of soup." Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From ckolar@aurora.edu Tue Aug 28 18:04:00 2001 From: ckolar@aurora.edu (Christopher Kolar) Date: Tue, 28 Aug 2001 12:04:00 -0500 Subject: [Mailman-Developers] * Mailman Docs Moving * Message-ID: <5.1.0.14.2.20010828120056.0287ba58@mail.aurora.edu> Hello everyone. I will be changing jobs this week and the mailman documentation will be moving with me. I will be looking through my logs to see if I can find people who have incoming links but things will be busy for me the next couple of days and I may note be able to contact people in a timely fashion; so if you link to the docs at www.aurora.edu/~ckolar/mailman please note that they will now be at: www.imsa.edu/~ckolar/mailman Cheers, --chris From claw@kanga.nu Tue Aug 28 18:54:33 2001 From: claw@kanga.nu (J C Lawrence) Date: Tue, 28 Aug 2001 10:54:33 -0700 Subject: [Mailman-Developers] Re: [Mailman-Users] * Mailman Docs Moving * In-Reply-To: Message from Christopher Kolar of "Tue, 28 Aug 2001 12:04:00 CDT." <5.1.0.14.2.20010828120056.0287ba58@mail.aurora.edu> References: <5.1.0.14.2.20010828120056.0287ba58@mail.aurora.edu> Message-ID: <17921.999021273@kanga.nu> On Tue, 28 Aug 2001 12:04:00 -0500 Christopher Kolar wrote: > Hello everyone. I will be changing jobs this week and the mailman > documentation will be moving with me. I will be looking through > my logs to see if I can find people who have incoming links but > things will be busy for me the next couple of days and I may note > be able to contact people in a timely fashion; so if you link to > the docs at www.aurora.edu/~ckolar/mailman please note that they > will now be at: > www.imsa.edu/~ckolar/mailman Would there be a problem with putting them directly on the Mailman site? -- J C Lawrence )\._.,--....,'``. ---------(*) /, _.. \ _\ ;`._ ,. claw@kanga.nu `._.-(,_..'--(,_..'`-.;.' http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly From barry@zope.com Tue Aug 28 19:49:17 2001 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 28 Aug 2001 14:49:17 -0400 Subject: [Mailman-Developers] Preventing spam to list admins. References: <9128.998980423@kanga.nu> Message-ID: <15243.59309.332105.36233@anthem.wooz.org> Here are some of my thoughts. I'm trying to temper the suggested solution by what I think is doable within the 2.1 time-frame. It won't be the ultimate solution (if there even is one), but it ought to be a good step in the right direction. First, I'm all for changing the footers so that the contact address is listname-owner@dom.ain instead of the individual admin's addresses. There's another reason why this is A Good Idea, and why I've been contemplating this change for a while now: it will discourage folks from emailing individual admins with questions that really should be seen and dealt with collaboratively. (Aside: I have plans post-2.1 to normalize address rosters so that admin and moderator rosters will be conceptually no different than "normal" mailing lists. This will allow you to do some useful things, like archive -admin/-owner traffic, apply more uniform spam detection, etc.) One downside of changing the contact address is that we don't currently keep Real Names for owner or moderators, so the /only/ thing we know about them is their email address. I don't plan on changing this for 2.1 so we can either say something like 1. "Contact the Mylist administrators", where contact is hyperlinked to the mailto: url of the -owner address. 2. Like now with a slight variation: "Mylist list run by barry at zope.com", where Mylist is hyperlinked to the listinfo page and "barry at zope.com" is mailto: linked to the -owner address. I think I prefer #2. Chuq brings up the issue of whether the moderators are included in email to -admin or -owner, and the current answer is no. I can see either adding a standard -moderators address, or always including the moderators in the -owner address. Then what about -admin? Currently the only distinction between -admin and -owner is that the former runs the bounce detector first. Should -admin go to the moderators too? To complete the circle, we can pass -owner messages through the SpamDetect.py filter, but not the Hold.py filter. This isn't ideal, because I don't think there will be time to make SpamDetect configurable thru-the-web for 2.1, but it does give a site admin /some/ ability to filter out the most egregious spammers. And I'll posit that spam detection/prevention filters really ought to be applied site-wide instead of per-list. I'm generally against putting the -owner/-admin addresses behind a CGI form, 1) because I've never seen a mail submission form that doesn't suck hard (it totally bypasses all the message composition tools I'm used to for all my other email handling, and usually never gives me a way around the form to enter into my address book); 2) if Mailman or its CGI is broken, most users will not be able to contact anybody, and to me that is a much worse sin than the admins getting some spam (but I'll admit that I'm as numb to spam as Chuq is). Would I like to do better? Yes. Will there be time for MM2.1? Probably not. Still, I think this will give a better story than for MM2.0. It's low-hanging, low-effort fruit, experience with which we'll learn whether we need to spend more effort to do better or not. -Barry From claw@kanga.nu Tue Aug 28 20:44:28 2001 From: claw@kanga.nu (J C Lawrence) Date: Tue, 28 Aug 2001 12:44:28 -0700 Subject: [Mailman-Developers] Preventing spam to list admins. In-Reply-To: Message from barry@zope.com (Barry A. Warsaw) of "Tue, 28 Aug 2001 14:49:17 EDT." <15243.59309.332105.36233@anthem.wooz.org> References: <9128.998980423@kanga.nu> <15243.59309.332105.36233@anthem.wooz.org> Message-ID: <19975.999027868@kanga.nu> On Tue, 28 Aug 2001 14:49:17 -0400 Barry A Warsaw wrote: > 1. "Contact the Mylist administrators", where contact is > hyperlinked to the mailto: url of the -owner address. > 2. Like now with a slight variation: "Mylist list run by barry > at zope.com", where Mylist is hyperlinked to the listinfo page and > "barry at zope.com" is mailto: linked to the -owner address. > I think I prefer #2. I very slightly prefer #1. I don't consider this a significant item however, #2 is just fine. > Chuq brings up the issue of whether the moderators are included in > email to -admin or -owner, and the current answer is no. I can > see either adding a standard -moderators address, or always > including the moderators in the -owner address. I consider "moderator" largely synonymous with "owner". Loosely the breakdown I use is: SiteOwner ListAdmin ListOwner == ListModerator ListMember > Then what about -admin? Currently the only distinction between > -admin and -owner is that the former runs the bounce detector > first. Should -admin go to the moderators too? Admin is useful for bounce processing (tho I'd prefer seeing that using a -bounce address rather than conflating it onto -admin as it makes filtering easier), and for those who actually have write privilege to the list configs (not just post approval). Actually, I'd *really* like to see bounce processing split out to its own address. > To complete the circle, we can pass -owner messages through the > SpamDetect.py filter, but not the Hold.py filter. This isn't > ideal, because I don't think there will be time to make SpamDetect > configurable thru-the-web for 2.1, but it does give a site admin > /some/ ability to filter out the most egregious spammers. And > I'll posit that spam detection/prevention filters really ought to > be applied site-wide instead of per-list. Grrrr. No. There's to much variation in what particular lists might want, especially in vhosting situations. -- J C Lawrence )\._.,--....,'``. ---------(*) /, _.. \ _\ ;`._ ,. claw@kanga.nu `._.-(,_..'--(,_..'`-.;.' http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly From barry@zope.com Tue Aug 28 21:35:46 2001 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 28 Aug 2001 16:35:46 -0400 Subject: [Mailman-Developers] Preventing spam to list admins. References: <9128.998980423@kanga.nu> <15243.59309.332105.36233@anthem.wooz.org> <19975.999027868@kanga.nu> Message-ID: <15244.162.482384.976795@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: >> 1. "Contact the Mylist administrators", where contact is >> hyperlinked to the mailto: url of the -owner address. >> 2. Like now with a slight variation: "Mylist list run by barry >> at zope.com", where Mylist is hyperlinked to the listinfo page >> and "barry at zope.com" is mailto: linked to the -owner >> address. >> I think I prefer #2. JCL> I very slightly prefer #1. I don't consider this a JCL> significant item however, #2 is just fine. Okay. >> Chuq brings up the issue of whether the moderators are included >> in email to -admin or -owner, and the current answer is no. I >> can see either adding a standard -moderators address, or always >> including the moderators in the -owner address. JCL> I consider "moderator" largely synonymous with "owner". JCL> Loosely the breakdown I use is: | SiteOwner | ListAdmin | ListOwner == ListModerator | ListMember Okay, I think I can live with that, even though strictly speaking "moderators" won't have all the privileges of "owners" (owners can hit the admin pages, while both groups can hit the admindb pages). >> Then what about -admin? Currently the only distinction between >> -admin and -owner is that the former runs the bounce detector >> first. Should -admin go to the moderators too? JCL> Admin is useful for bounce processing (tho I'd prefer seeing JCL> that using a -bounce address rather than conflating it onto JCL> -admin as it makes filtering easier), and for those who JCL> actually have write privilege to the list configs (not just JCL> post approval). JCL> Actually, I'd *really* like to see bounce processing split JCL> out to its own address. Me too. I remember we had a thread about this a while back. Doing so would require regeneration of your alias database, which I seem to recall was considered to disruptive to backwards compatibility to adopt for MM2.1. Maybe we should reconsider (or perhaps I remember the decision incorrectly). >> To complete the circle, we can pass -owner messages through the >> SpamDetect.py filter, but not the Hold.py filter. This isn't >> ideal, because I don't think there will be time to make >> SpamDetect configurable thru-the-web for 2.1, but it does give >> a site admin /some/ ability to filter out the most egregious >> spammers. And I'll posit that spam detection/prevention >> filters really ought to be applied site-wide instead of >> per-list. JCL> Grrrr. No. There's to much variation in what particular JCL> lists might want, especially in vhosting situations. I'm not saying that vhosts and/or lists shouldn't be able to augment site-specific spam controls, but I also don't want to burden every list admin with having to install their own spam controls to block /anything/. It's analogous to MTA spam blocks, which by their nature are site-wide. Remember that in post-2.1 I plan on implementing delegation of configuration: site->vhost->list(->user). -Barry From jra@baylink.com Tue Aug 28 22:58:10 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 28 Aug 2001 17:58:10 -0400 Subject: [Mailman-Developers] Preventing spam to list admins. In-Reply-To: <15243.59309.332105.36233@anthem.wooz.org>; from "Barry A. Warsaw" on Tue, Aug 28, 2001 at 02:49:17PM -0400 References: <9128.998980423@kanga.nu> <15243.59309.332105.36233@anthem.wooz.org> Message-ID: <20010828175810.38518@scfn.thpl.lib.fl.us> On Tue, Aug 28, 2001 at 02:49:17PM -0400, Barry A. Warsaw wrote: > I'm generally against putting the -owner/-admin addresses behind a CGI > form, 1) because I've never seen a mail submission form that doesn't > suck hard (it totally bypasses all the message composition tools I'm > used to for all my other email handling, and usually never gives me a > way around the form to enter into my address book) I want to take a moment here to agree violently. I *HATE* mail forms, with an unbridled passion. The worse thing, Barry, which you neglect to mention, is that you don't get a copy in your Sent folder either. Some cgi's are at least polite enough to CC you, but they're few and far between. No: Down With MailForms. 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 804 5015 "So easy to use, no wonder the Internet is going to hell!" -- me From chuqui@plaidworks.com Tue Aug 28 23:04:17 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 28 Aug 2001 15:04:17 -0700 Subject: [Mailman-Developers] Preventing spam to list admins. In-Reply-To: <20010828175810.38518@scfn.thpl.lib.fl.us> Message-ID: On 8/28/01 2:58 PM, "Jay R. Ashworth" wrote: > I *HATE* mail forms, with an unbridled passion. The worse thing, > Barry, which you neglect to mention, is that you don't get a copy in > your Sent folder either. Some cgi's are at least polite enough to CC > you, but they're few and far between. So -- how do we do it? Could we create a mini-form that you push a submit button, and it brings up a mail-to link? I think that would stop spambots, no? Any better ideas? -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. 95% of being a net.god is sounding persuasive and convincing people you know what you're talking about, even when you're making it up as you go along. (chuq von rospach, 1992) From ricardo@rixhq.nu Tue Aug 28 23:56:38 2001 From: ricardo@rixhq.nu (Ricardo F. Kustner) Date: Wed, 29 Aug 2001 00:56:38 +0200 Subject: [Mailman-Developers] Fw: Re: [Mailman-Users] Digest Problems Message-ID: <20010829005638.6fa35c3b.ricardo@rixhq.nu> I just saw this post on the mailman-users list... it seems that you can easily break mailman by improperly using '%' chars in the digest footer... has this issue been addressed before? will this still happen in 2.0.6 and 2.1a ? I can imagine that in large mailman installations, with many different lists and listadmins, this could cause problems... Begin forwarded message: Date: Tue, 28 Aug 2001 16:14:56 -0700 From: "Ashley M. Kirchner" To: "Ricardo F. Kustner" Subject: Re: [Mailman-Users] Digest Problems "Ricardo F. Kustner" wrote: > This is just a wild guess... but did somebody recently edit the list > templates or the digest footer info on the admin page? I remember getting > errors once while I had some misformed template variables in one of the > templates... so might want to have a look in either place... Yeap. That's what it was. However, this now brings me to my next question: Which characters are trouble characters? As in, which ones needs to be escaped? % ? ! ? My client had put something similar to this in the footer: /30-70% (with the / prefixed) and somewhere further down the line, he had '/EVC' (again prefixed with the / ). Those /'s weren't mistakes, they were put there by him (for whatever reason), however are those characters (whether %, ! or / )the trouble makers, and if so, how CAN they be used? -- Regards, Ricardo From jra@baylink.com Wed Aug 29 00:28:41 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Tue, 28 Aug 2001 19:28:41 -0400 Subject: [Mailman-Developers] Preventing spam to list admins. In-Reply-To: ; from Chuq Von Rospach on Tue, Aug 28, 2001 at 03:04:17PM -0700 References: <20010828175810.38518@scfn.thpl.lib.fl.us> Message-ID: <20010828192841.63131@scfn.thpl.lib.fl.us> On Tue, Aug 28, 2001 at 03:04:17PM -0700, Chuq Von Rospach wrote: > On 8/28/01 2:58 PM, "Jay R. Ashworth" wrote: > > I *HATE* mail forms, with an unbridled passion. The worse thing, > > Barry, which you neglect to mention, is that you don't get a copy in > > your Sent folder either. Some cgi's are at least polite enough to CC > > you, but they're few and far between. > > So -- how do we do it? > > Could we create a mini-form that you push a submit button, and it brings up > a mail-to link? I think that would stop spambots, no? Any better ideas? That might work. Think Lynx and wireless; there are *lots* of non-graphical browsers out there... 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 804 5015 "So easy to use, no wonder the Internet is going to hell!" -- me From barry@zope.com Wed Aug 29 03:19:44 2001 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 28 Aug 2001 22:19:44 -0400 Subject: [Mailman-Developers] Preventing spam to list admins. References: <9128.998980423@kanga.nu> <15243.59309.332105.36233@anthem.wooz.org> <20010828175810.38518@scfn.thpl.lib.fl.us> Message-ID: <15244.20800.394655.781733@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: >> I'm generally against putting the -owner/-admin addresses >> behind a CGI form, 1) because I've never seen a mail submission >> form that doesn't suck hard (it totally bypasses all the >> message composition tools I'm used to for all my other email >> handling, and usually never gives me a way around the form to >> enter into my address book) JRA> I want to take a moment here to agree violently. No need to turn purple there Jay... oh wait "violently", not "violetly". JRA> I *HATE* mail forms, with an unbridled passion. The worse JRA> thing, Barry, which you neglect to mention, is that you don't JRA> get a copy in your Sent folder either. Some cgi's are at JRA> least polite enough to CC you, but they're few and far JRA> between. Good point. JRA> No: Down With MailForms. >>>>> "CVR" == Chuq Von Rospach writes: CVR> So -- how do we do it? CVR> Could we create a mini-form that you push a submit button, CVR> and it brings up a mail-to link? I think that would stop CVR> spambots, no? Any better ideas? Ug. Sorry Chuq, but something in me really riles against making the user go through so many hoops to contact a person. It reminds me of endless voicemail menus and seemingly infinite hold times. Shouldn't we err on the side of pissing off admins more than pissing off users? (Granted, reducing the urine splatter on our poor overtaxed admins as much as possible.[1]) Besides, how long will it be before the harvesters start following simply form posts? Won't any form more complicated than a submit button just infuriate frustrated users even more? I'd still like to at least try the suggestion I made earlier to see if that helps stem the most egregious spammers. -Barry [1] Sorry. ;) As my dad is fond of saying: "it's better to be pissed off than pissed on". From claw@kanga.nu Wed Aug 29 03:49:28 2001 From: claw@kanga.nu (J C Lawrence) Date: Tue, 28 Aug 2001 19:49:28 -0700 Subject: [Mailman-Developers] Preventing spam to list admins. In-Reply-To: Message from barry@zope.com (Barry A. Warsaw) of "Tue, 28 Aug 2001 16:35:46 EDT." <15244.162.482384.976795@anthem.wooz.org> References: <9128.998980423@kanga.nu> <15243.59309.332105.36233@anthem.wooz.org> <19975.999027868@kanga.nu> <15244.162.482384.976795@anthem.wooz.org> Message-ID: <24249.999053368@kanga.nu> On Tue, 28 Aug 2001 16:35:46 -0400 Barry A Warsaw wrote: >>>>>> "JCL" == J C Lawrence writes: > | SiteOwner | ListAdmin | ListOwner == ListModerator | > ListMember > Okay, I think I can live with that, even though strictly speaking > "moderators" won't have all the privileges of "owners" (owners can > hit the admin pages, while both groups can hit the admindb pages). I'm counting ListAdmin and above as the only one able to hit the admin page. ListOwner/Moderator can only hit the admindb pages and everything below, and members, well, they can hit their options. >>> Then what about -admin? Currently the only distinction between >>> -admin and -owner is that the former runs the bounce detector >>> first. Should -admin go to the moderators too? JCL> Admin is useful for bounce processing (tho I'd prefer seeing JCL> that using a -bounce address rather than conflating it onto JCL> -admin as it makes filtering easier), and for those who JCL> actually have write privilege to the list configs (not just JCL> post approval). JCL> Actually, I'd *really* like to see bounce processing split out JCL> to its own address. > Me too. I remember we had a thread about this a while back. > Doing so would require regeneration of your alias database, which > I seem to recall was considered to disruptive to backwards > compatibility to adopt for MM2.1. Maybe we should reconsider (or > perhaps I remember the decision incorrectly). It would be disruptive. I was hesitant to recommend for 2.1 as at the time it was looked at as an incremental release. This is no longer true. 2.1 at this point almost (perhaps not quite) warrants a pull number increment. Certainly 2.1 already has a list of backward incompatabilities (qrunner/cronjobs, mimelib, etc). I don't see much problem splitting it out into its own address concurrently with 2.1, and frankly, I'd rather get the pain over sooner than later. >>> To complete the circle, we can pass -owner messages through the >>> SpamDetect.py filter, but not the Hold.py filter. This isn't >>> ideal, because I don't think there will be time to make >>> SpamDetect configurable thru-the-web for 2.1, but it does give a >>> site admin /some/ ability to filter out the most egregious >>> spammers. And I'll posit that spam detection/prevention filters >>> really ought to be applied site-wide instead of per-list. JCL> Grrrr. No. There's to much variation in what particular lists JCL> might want, especially in vhosting situations. > I'm not saying that vhosts and/or lists shouldn't be able to > augment site-specific spam controls, but I also don't want to > burden every list admin with having to install their own spam > controls to block /anything/. It's analogous to MTA spam blocks, > which by their nature are site-wide. > Remember that in post-2.1 I plan on implementing delegation of > configuration: site->vhost->list(->user). Quite, so we're going to get a hierarchy of config values and ranges. Site installation has a set of configs which all lists inherit and can't create exceptions to. Which really raises the question of definition strength. If you have such a layered model with each level inheriting the values from above and (generally) not able to do anything except more go tighter/more_limited than their parent it makes creating exceptions nightmarish. While it adds a horrible level of complexity, what I'd suggest is doing a two layer job: Definitions at each level which lower levels CANNOT override. Definitions at each level which provide defaults, but which can be overridden. In the first category would fit Chuq's list and the ListReplyTo setting. In the latter category might fit site SPAM checking suggestions. -- J C Lawrence )\._.,--....,'``. ---------(*) /, _.. \ _\ ;`._ ,. claw@kanga.nu `._.-(,_..'--(,_..'`-.;.' http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly From barry@zope.com Wed Aug 29 04:01:06 2001 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 28 Aug 2001 23:01:06 -0400 Subject: [Mailman-Developers] Preventing spam to list admins. References: <9128.998980423@kanga.nu> <15243.59309.332105.36233@anthem.wooz.org> <19975.999027868@kanga.nu> <15244.162.482384.976795@anthem.wooz.org> <24249.999053368@kanga.nu> Message-ID: <15244.23282.543425.101991@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: JCL> I'm counting ListAdmin and above as the only one able to hit JCL> the admin page. ListOwner/Moderator can only hit the admindb JCL> pages and everything below, and members, well, they can hit JCL> their options. Agreed. >> Me too. I remember we had a thread about this a while back. >> Doing so would require regeneration of your alias database, >> which I seem to recall was considered to disruptive to >> backwards compatibility to adopt for MM2.1. Maybe we should >> reconsider (or perhaps I remember the decision incorrectly). JCL> It would be disruptive. I was hesitant to recommend for 2.1 JCL> as at the time it was looked at as an incremental release. JCL> This is no longer true. 2.1 at this point almost (perhaps JCL> not quite) warrants a pull number increment. Certainly 2.1 JCL> already has a list of backward incompatabilities JCL> (qrunner/cronjobs, mimelib, etc). I don't see much problem JCL> splitting it out into its own address concurrently with 2.1, JCL> and frankly, I'd rather get the pain over sooner than later. You've been reading my mind, you know. I've been hesitant to suggest this, but for quite some time I've thought that the next release ought to be 3.0 intead of 2.1. I've stopped short of that because 1) what I promised would be in a 2.1 release; 2) I've been talking about "MM2.1" for so long now; 3) all the things I've been pushing off to MM3.0. I really really really want to get the next release out as soon as possible. I don't want a decision to call this thing MM3.0 to mean a delay in the release schedule. But truth-in-advertising makes me think it really should be called 3.0. OTOH, will that deter too many people from upgrading? Sigh, I don't know. Opinions? I'd like to make a final decision on this by the first beta. (Remember, there /will/ be one more alpha... RSN! ;). JCL> Which really raises the question of definition strength. If JCL> you have such a layered model with each level inheriting the JCL> values from above and (generally) not able to do anything JCL> except more go tighter/more_limited than their parent it JCL> makes creating exceptions nightmarish. While it adds a JCL> horrible level of complexity, what I'd suggest is doing a two JCL> layer job: JCL> Definitions at each level which lower levels CANNOT JCL> override. JCL> Definitions at each level which provide defaults, but which JCL> can be overridden. This is much more what I've been thinking of doing. You're right that doing it the other way would probably be just too complicated and error prone. JCL> In the first category would fit Chuq's list and the JCL> ListReplyTo setting. In the latter category might fit site JCL> SPAM checking suggestions. -Barry From claw@kanga.nu Wed Aug 29 04:19:08 2001 From: claw@kanga.nu (J C Lawrence) Date: Tue, 28 Aug 2001 20:19:08 -0700 Subject: [Mailman-Developers] Preventing spam to list admins. In-Reply-To: Message from barry@zope.com (Barry A. Warsaw) of "Tue, 28 Aug 2001 23:01:06 EDT." <15244.23282.543425.101991@anthem.wooz.org> References: <9128.998980423@kanga.nu> <15243.59309.332105.36233@anthem.wooz.org> <19975.999027868@kanga.nu> <15244.162.482384.976795@anthem.wooz.org> <24249.999053368@kanga.nu> <15244.23282.543425.101991@anthem.wooz.org> Message-ID: <24548.999055148@kanga.nu> On Tue, 28 Aug 2001 23:01:06 -0400 Barry A Warsaw wrote: >>>>>> "JCL" == J C Lawrence writes: > You've been reading my mind, you know. I've been hesitant to > suggest this, but for quite some time I've thought that the next > release ought to be 3.0 intead of 2.1. I've stopped short of that > because 1) what I promised would be in a 2.1 release; 2) I've been > talking about "MM2.1" for so long now; 3) all the things I've been > pushing off to MM3.0. Heh. It sounds like in the tradition of all the best open source projects all the real work for 3.0 ill be done in 2.x with the 3.0 release being a retrospective, "Oh yeah, that worked!" release. > I really really really want to get the next release out as soon as > possible. I don't want a decision to call this thing MM3.0 to > mean a delay in the release schedule. But truth-in-advertising > makes me think it really should be called 3.0. OTOH, will that > deter too many people from upgrading? Sigh, I don't know. > Opinions? Leave it at 2.1. It doesn't hurt anything. Changing would hurt things. We can always roll 3.0 later when we change the background colours for the web forms or something. > I'd like to make a final decision on this by the first beta. > (Remember, there /will/ be one more alpha... RSN! ;). Frankly my dear, I don't give a damn about version numbers. JCL> Definitions at each level which lower levels CANNOT override. JCL> Definitions at each level which provide defaults, but which can JCL> be overridden. > This is much more what I've been thinking of doing. Excellent. > You're right that doing it the other way would probably be just > too complicated and error prone. The thing I like about spitting them that way is that we can make the UI modal (you see #1 or #2) so you only see that set of definitions. Given clear lead in statements it should be workable. -- J C Lawrence )\._.,--....,'``. ---------(*) /, _.. \ _\ ;`._ ,. claw@kanga.nu `._.-(,_..'--(,_..'`-.;.' http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly From chuqui@plaidworks.com Wed Aug 29 04:27:13 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 28 Aug 2001 20:27:13 -0700 Subject: [Mailman-Developers] Preventing spam to list admins. In-Reply-To: <15244.20800.394655.781733@anthem.wooz.org> Message-ID: On 8/28/01 7:19 PM, "Barry A. Warsaw" wrote: > Ug. Sorry Chuq, but something in me really riles against making the > user go through so many hoops to contact a person. Yah, I know. This is a situation where we're going to have to make a compromise somewhere, either in protection or easy of use. Or perhaps against both at the same time. I"m throwing stuff out in hopes it causes someone to come up with a GOOD idea. I'm sure not. > Besides, how long will it be before the harvesters start following > simply form posts? Won't any form more complicated than a submit > button just infuriate frustrated users even more? Worrisome, but frankly, I'd save that worry for when it happens, unless we can find a way we like that also solves it. If we wait for a 100% solution, we'll die of old age. So we're going to, at some point, have to stuff our fingers in the dike and hope, at least until we can build a better dike. -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. Q: Did God really create the world in seven days? A: He did it in six days and nights while living on cola and candy bars. On the seventh day he went home and found out his girlfriend had left him. From chuqui@plaidworks.com Wed Aug 29 04:29:16 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Tue, 28 Aug 2001 20:29:16 -0700 Subject: [Mailman-Developers] Preventing spam to list admins. In-Reply-To: <15244.23282.543425.101991@anthem.wooz.org> Message-ID: On 8/28/01 8:01 PM, "Barry A. Warsaw" wrote: > 1) what I > promised would be in a 2.1 release; 2) I've been talking about "MM2.1" > for so long now; 3) all the things I've been pushing off to MM3.0. FWIW, I like the current naming and how you're structuring it. I'd probably, since you're trying to go beta, formalize it by offically denying things that change apis and file formats to the greatest extent possible (i.e., unless it fixes a really nasty bug or security hole) and work at stabilizing 2.1 and get it out the door. -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. I'm out of my mind, but feel free to leave a message... From barry@zope.com Wed Aug 29 04:52:51 2001 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 28 Aug 2001 23:52:51 -0400 Subject: [Mailman-Developers] Preventing spam to list admins. References: <15244.20800.394655.781733@anthem.wooz.org> Message-ID: <15244.26387.732556.558689@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: >> Ug. Sorry Chuq, but something in me really riles against >> making the user go through so many hoops to contact a person. CVR> Yah, I know. This is a situation where we're going to have to CVR> make a compromise somewhere, either in protection or easy of CVR> use. Or perhaps against both at the same time. I"m throwing CVR> stuff out in hopes it causes someone to come up with a GOOD CVR> idea. I'm sure not. >> Besides, how long will it be before the harvesters start >> following simply form posts? Won't any form more complicated >> than a submit button just infuriate frustrated users even more? CVR> Worrisome, but frankly, I'd save that worry for when it CVR> happens, unless we can find a way we like that also solves CVR> it. If we wait for a 100% solution, we'll die of old age. So CVR> we're going to, at some point, have to stuff our fingers in CVR> the dike and hope, at least until we can build a better dike. Good points, Chuq, thanks. -Barry From dgc@uchicago.edu Wed Aug 29 04:59:21 2001 From: dgc@uchicago.edu (David Champion) Date: Tue, 28 Aug 2001 22:59:21 -0500 Subject: [Mailman-Developers] Re: Preventing spam to list admins. In-Reply-To: <24548.999055148@kanga.nu> References: <9128.998980423@kanga.nu> <15243.59309.332105.36233@anthem.wooz.org> <19975.999027868@kanga.nu> <15244.162.482384.976795@anthem.wooz.org> <24249.999053368@kanga.nu> <15244.23282.543425.101991@anthem.wooz.org> <24548.999055148@kanga.nu> Message-ID: <20010828225921.V892@smack.uchicago.edu> On 2001.08.28, in <24548.999055148@kanga.nu>, "J C Lawrence" wrote: > > Heh. It sounds like in the tradition of all the best open source > projects all the real work for 3.0 ill be done in 2.x with the 3.0 > release being a retrospective, "Oh yeah, that worked!" release. Could call it 2.99, just to aggrieve version-number zealots (like me). 'Course, if you were really after my goat, you'd start making "stable" releases even-numbered, and "development" releases odd.... -- -D. dgc@uchicago.edu NSIT University of Chicago From barry@zope.com Wed Aug 29 04:59:42 2001 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 28 Aug 2001 23:59:42 -0400 Subject: [Mailman-Developers] Preventing spam to list admins. References: <15244.23282.543425.101991@anthem.wooz.org> Message-ID: <15244.26798.343917.485118@anthem.wooz.org> >>>>> "CVR" == Chuq Von Rospach writes: >> 1) what I promised would be in a 2.1 release; 2) I've been >> talking about "MM2.1" for so long now; 3) all the things I've >> been pushing off to MM3.0. CVR> FWIW, I like the current naming and how you're structuring CVR> it. I'd probably, since you're trying to go beta, formalize CVR> it by offically denying things that change apis and file CVR> formats to the greatest extent possible (i.e., unless it CVR> fixes a really nasty bug or security hole) and work at CVR> stabilizing 2.1 and get it out the door. I think the one (possible) looming big change is mimelib. Guido's accepted it into the standard library, but it's going to be called the "email" package. I'm working on cleaning that up and commiting it to Py2.2. I think I've pretty much decided though that for Mailman we'll stick with mimelib as it stands in its SF project, with perhaps a minor tweak here and there. I haven't quite decided how to bundle it with Mailman (either as a distutils thing the Mailman installation process installs automatically, or as a subdirectory of Mailman/pythonlib). I think I won't change Mailman until Python 2.2 is required (don't expect that soon, given that Python 2.2 is itself not in beta). That is unless it gets too hard to maintain two sets of the mimelib code base. -Barry From barry@zope.com Wed Aug 29 05:07:25 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 29 Aug 2001 00:07:25 -0400 Subject: [Mailman-Developers] Re: Preventing spam to list admins. References: <9128.998980423@kanga.nu> <15243.59309.332105.36233@anthem.wooz.org> <19975.999027868@kanga.nu> <15244.162.482384.976795@anthem.wooz.org> <24249.999053368@kanga.nu> <15244.23282.543425.101991@anthem.wooz.org> <24548.999055148@kanga.nu> <20010828225921.V892@smack.uchicago.edu> Message-ID: <15244.27261.642833.963531@anthem.wooz.org> >>>>> "DC" == David Champion writes: DC> Could call it 2.99, just to aggrieve version-number zealots DC> (like me). Oh, oh, I know! Mailman 2001. We'll corner the Windows market in no time. DC> 'Course, if you were really after my goat, you'd start making DC> "stable" releases even-numbered, and "development" releases DC> odd.... Aauuugggh, no! have-enough-goats-as-it-is-ly y'rs, -Barry From alaric@babcom.com Mon Aug 27 19:28:23 2001 From: alaric@babcom.com (Phil Stracchino) Date: Mon, 27 Aug 2001 11:28:23 -0700 Subject: [Mailman-Developers] Preventing spam to list admins. In-Reply-To: <20010827133935.47122@scfn.thpl.lib.fl.us>; from jra@baylink.com on Mon, Aug 27, 2001 at 01:39:35PM -0400 References: <20010827133935.47122@scfn.thpl.lib.fl.us> Message-ID: <20010827112823.A3789@babylon5.babcom.com> On Mon, Aug 27, 2001 at 01:39:35PM -0400, Jay R. Ashworth wrote: > We ought to hunt down spammers who address harvest, and string them up. > > I am *not* kidding. s/ who address harvest//; -- Linux Now! ..........Because friends don't let friends use Microsoft. phil stracchino -- the renaissance man -- mystic zen biker geek alaric@babcom.com halmayne@sourceforge.net 2000 CBR929RR, 1991 VFR750F3 (foully murdered), 1986 VF500F (sold) From jra@baylink.com Wed Aug 29 15:26:22 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 29 Aug 2001 10:26:22 -0400 Subject: [Mailman-Developers] Preventing spam to list admins. In-Reply-To: <20010827112823.A3789@babylon5.babcom.com>; from Phil Stracchino on Mon, Aug 27, 2001 at 11:28:23AM -0700 References: <20010827133935.47122@scfn.thpl.lib.fl.us> <20010827112823.A3789@babylon5.babcom.com> Message-ID: <20010829102622.05763@scfn.thpl.lib.fl.us> On Mon, Aug 27, 2001 at 11:28:23AM -0700, Phil Stracchino wrote: > On Mon, Aug 27, 2001 at 01:39:35PM -0400, Jay R. Ashworth wrote: > > We ought to hunt down spammers who address harvest, and string them up. > > I am *not* kidding. > > s/ who address harvest//; And you even got the leading space. Excellent attention to detail, young man. ;-) 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 804 5015 "So easy to use, no wonder the Internet is going to hell!" -- me From jra@baylink.com Wed Aug 29 15:29:24 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 29 Aug 2001 10:29:24 -0400 Subject: [Mailman-Developers] Preventing spam to list admins. In-Reply-To: <15244.23282.543425.101991@anthem.wooz.org>; from "Barry A. Warsaw" on Tue, Aug 28, 2001 at 11:01:06PM -0400 References: <9128.998980423@kanga.nu> <15243.59309.332105.36233@anthem.wooz.org> <19975.999027868@kanga.nu> <15244.162.482384.976795@anthem.wooz.org> <24249.999053368@kanga.nu> <15244.23282.543425.101991@anthem.wooz.org> Message-ID: <20010829102924.63244@scfn.thpl.lib.fl.us> On Tue, Aug 28, 2001 at 11:01:06PM -0400, Barry A. Warsaw wrote: > >> Me too. I remember we had a thread about this a while back. > >> Doing so would require regeneration of your alias database, > >> which I seem to recall was considered to disruptive to > >> backwards compatibility to adopt for MM2.1. Maybe we should > >> reconsider (or perhaps I remember the decision incorrectly). > > JCL> It would be disruptive. I was hesitant to recommend for 2.1 > JCL> as at the time it was looked at as an incremental release. > JCL> This is no longer true. 2.1 at this point almost (perhaps > JCL> not quite) warrants a pull number increment. Certainly 2.1 > JCL> already has a list of backward incompatabilities > JCL> (qrunner/cronjobs, mimelib, etc). I don't see much problem > JCL> splitting it out into its own address concurrently with 2.1, > JCL> and frankly, I'd rather get the pain over sooner than later. > > You've been reading my mind, you know. I've been hesitant to suggest > this, but for quite some time I've thought that the next release ought > to be 3.0 intead of 2.1. I've stopped short of that because 1) what I > promised would be in a 2.1 release; 2) I've been talking about "MM2.1" > for so long now; 3) all the things I've been pushing off to MM3.0. > > I really really really want to get the next release out as soon as > possible. I don't want a decision to call this thing MM3.0 to mean a > delay in the release schedule. But truth-in-advertising makes me > think it really should be called 3.0. OTOH, will that deter too many > people from upgrading? Sigh, I don't know. Opinions? Someone who *cares*. Wow. I'm afraid I agree with JC; if there are that many fundamental changes, perhaps a major rev is indeed called for. Don't let the lack of a 2.1 deter you from that... but if you're going to have to slip too much, I concur, do 2.1 and put off the 3.0 stuff till 3.0. (I forget: is the announcment list stuff in (the current) 2.1?) 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 804 5015 "So easy to use, no wonder the Internet is going to hell!" -- me From mlogemann@morelogs.de Wed Aug 29 16:45:27 2001 From: mlogemann@morelogs.de (Marc Logemann) Date: Wed, 29 Aug 2001 17:45:27 +0200 Subject: [Mailman-Developers] Diff of subscribe.py Message-ID: Hi, a few days ago i mentioned a bug in subscribe.py, resulting in wrong HTML output (i posted it in mailman-users...sorry for that). There were allways some html lines, which do not come from the template but from the script/binary itself. The extra lines were also wrong in terms of HTML compliance. I modified it, that from now on, the subscribe.py is doing the same way th= an listinfo.py, which has no problems regarding templates. below a diff for subscribe.py in /cgi folder: 35c35 < doc =3D Document() --- > doc =3D HeadlessDocument() 40c40 < print doc.Format(bgcolor=3D"#ffffff") --- > print doc.Format() 49c49 < print doc.Format(bgcolor=3D"#ffffff") --- > print doc.Format() 111c111 < print doc.Format(bgcolor=3D"#ffffff") --- > print doc.Format() 121c121 < print doc.Format(bgcolor=3D"#ffffff") --- > print doc.Format() 241c241 < print doc.Format(bgcolor=3D"#ffffff") --- > print doc.Format() Can we go on with this version? Or are there any drawbacks? From my point = of view this seems to work well for "standard" and "customized" subscription-resul= ts templates. morelogs | Marc Logemann, chief evangelist ____________________________________________________________ Rellinghauser Str. 332 =B7 D-45136 Essen =B7 Germany T: +49 201 84 188-177 =B7 F: +49 201 84 188-199 mlogemann@morelogs.de =B7 http://www.morelogs.de From barry@zope.com Wed Aug 29 18:02:22 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 29 Aug 2001 13:02:22 -0400 Subject: [Mailman-Developers] Diff of subscribe.py References: Message-ID: <15245.8222.673382.217448@anthem.wooz.org> >>>>> "ML" == Marc Logemann writes: ML> a few days ago i mentioned a bug in subscribe.py, resulting in ML> wrong HTML output (i posted it in mailman-users...sorry for ML> that). There were allways some html lines, which do not come ML> from the template but from the script/binary itself. The extra ML> lines were also wrong in terms of HTML compliance. I think several people have suggested this for MM2.0.x. It shouldn't be a problem anymore in MM2.1. -Barry From barry@zope.com Wed Aug 29 18:08:11 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 29 Aug 2001 13:08:11 -0400 Subject: [Mailman-Developers] Preventing spam to list admins. References: <9128.998980423@kanga.nu> <15243.59309.332105.36233@anthem.wooz.org> <19975.999027868@kanga.nu> <15244.162.482384.976795@anthem.wooz.org> <24249.999053368@kanga.nu> <15244.23282.543425.101991@anthem.wooz.org> <20010829102924.63244@scfn.thpl.lib.fl.us> Message-ID: <15245.8571.458153.617244@anthem.wooz.org> >>>>> "JRA" == Jay R Ashworth writes: JRA> Someone who *cares*. Wow. I'm afraid I agree with JC; if JRA> there are that many fundamental changes, perhaps a major rev JRA> is indeed called for. Don't let the lack of a 2.1 deter you JRA> from that... but if you're going to have to slip too much, I JRA> concur, do 2.1 and put off the 3.0 stuff till 3.0. (I JRA> forget: is the announcment list stuff in (the current) 2.1?) Which announcement list stuff? Do you mean personalized lists? Yup, that's in 2.1. Was there more that needed to be done for "announcement lists"? -Barry From barry@zope.com Wed Aug 29 18:30:05 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 29 Aug 2001 13:30:05 -0400 Subject: [Mailman-Developers] [PATCH] Modifying #! env python line to match --with-python References: <87itf88yxu.fsf@nausicaa.interq.or.jp> Message-ID: <15245.9885.712218.961251@anthem.wooz.org> >>>>> "BG" == Ben Gertzfield writes: BG> Many, many utility programs and other scripts that are in BG> Mailman CVS have #! /usr/bin/env python hard-coded in them, BG> and do not use the @PYTHON@ symbol exported from autoconf. BG> This means that the --with-python flag cannot be ever used if BG> python is not named "python"; for Debian Linux, this is a Big BG> Problem, because the python 1.6 and python 2.0 binaries have BG> different names. (/usr/bin/python vs /usr/bin/python2). BG> So, I created a patch that makes building possible when python BG> is called *anything*; I've tested it on Debian GNU/Linux BG> unstable, where python is called python2, and it works. BG> The patch (it's 500K, because it renames a lot of files) is BG> available at: This is the primary reason why I don't want to apply the patch. It's much less pain IMO to add a little shell script called "python" somewhere earlier in your path than /usr/bin. That's the whole reason why python is called through /usr/bin/env. I understand that it can be inconvenient to hack your $path, but it is less than the pain of trying to retain the CVS history of those files through the SF repository. BG> 4) Removes misc/mailman on a make distclean Good catch, thanks. BG> There are some files in the Mailman CVS tree that have #! BG> /usr/bin/env python lines, but are never really executed. I BG> didn't munge these files, because forcing folks to guess that BG> SOME files in the Mailman source tree are .in and others BG> aren't is icky These files are: | ./Mailman/Post.py:#! /usr/bin/env python This is on purpose since the Post.py script is designed to be called from the command line. | ./Mailman/Archiver/pipermail.py:#! /usr/bin/env python This is probably a holdover from an earlier time. Not worth worrying about. | ./misc/Cookie.py:#!/usr/bin/env python Basically, a contributed script. Probably going away soon in MM2.1 since Python 2.0 provides a Cookie.py (although I have to check for compatibility). -Barry From haroldp@sierraweb.com Wed Aug 29 18:53:43 2001 From: haroldp@sierraweb.com (Harold Paulson) Date: Wed, 29 Aug 2001 10:53:43 -0700 Subject: [Mailman-Developers] sendmail Message-ID: Hi, Won't this start Sendmail up listing ONLY on the alternate port? Since most of us run Mailman as an *extra* feature on our mail servers, this probably isn't what people will want. Is there a simple CLI way to start up Sendmail listening in the usual skeptical way on 25, AND in just-do-what-you-are-told mode on a local port? - H On Sun, 12 Aug 2001 23:26:54, "Chuq Von Rospach" wrote: I did this a little differently, since I know that tweaking sendmail.cf files gives many people hives, and so people aren't likely to do it. It's also unneccesary. You can do this without modifying your sendmail files at all. Instead, in your startup script, add: /usr/sbin/sendmail -bd -ODeliveryMode=defer \ -ODaemonPortOptions=Name=MSA,Port=NNNN,M=E,Addr=127.0.0.1 Where NNNN is some port number not otherwise used (you can test if something's in use by doing "telnet localhost NNNN" -- if it's refused, there's no daemon listening) This sets up a sendmail process listening to the alternate port, in DEFER mode, but set to talk only to the localhost interface, so it's not accessible by anyoneother than your local machine: no open relay problems. -- Harold Paulson Sierra Web Design haroldp@sierraweb.com http://www.sierraweb.com VOICE: 775.833.9500 FAX: 810.314.1517 From barry@zope.com Wed Aug 29 19:13:11 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 29 Aug 2001 14:13:11 -0400 Subject: [Mailman-Developers] [PATCH] CVS typo fix: Let users actually set options References: <87ae0k5s16.fsf@nausicaa.interq.or.jp> Message-ID: <15245.12471.453536.600152@anthem.wooz.org> >>>>> "BG" == Ben Gertzfield writes: BG> Big oops in the CVS, Barry! BG> I was struggling to understand why, with my new code to let BG> users avoid duplicate messages, I couldn't get the options for BG> any user to change.. turns out there was a silly typo in BG> Mailman/OldStyleMemberships.py which had been preventing all BG> users from EVER setting any options in CVS Mailman. BG> Patch follows, and is pretty self-evident when you look at it. D'oh! Thanks. From jra@baylink.com Wed Aug 29 19:25:25 2001 From: jra@baylink.com (Jay R. Ashworth) Date: Wed, 29 Aug 2001 14:25:25 -0400 Subject: [Mailman-Developers] Preventing spam to list admins. In-Reply-To: <15245.8571.458153.617244@anthem.wooz.org>; from "Barry A. Warsaw" on Wed, Aug 29, 2001 at 01:08:11PM -0400 References: <9128.998980423@kanga.nu> <15243.59309.332105.36233@anthem.wooz.org> <19975.999027868@kanga.nu> <15244.162.482384.976795@anthem.wooz.org> <24249.999053368@kanga.nu> <15244.23282.543425.101991@anthem.wooz.org> <20010829102924.63244@scfn.thpl.lib.fl.us> <15245.8571.458153.617244@anthem.wooz.org> Message-ID: <20010829142525.48952@scfn.thpl.lib.fl.us> On Wed, Aug 29, 2001 at 01:08:11PM -0400, Barry A. Warsaw wrote: > >>>>> "JRA" == Jay R Ashworth writes: > JRA> Someone who *cares*. Wow. I'm afraid I agree with JC; if > JRA> there are that many fundamental changes, perhaps a major rev > JRA> is indeed called for. Don't let the lack of a 2.1 deter you > JRA> from that... but if you're going to have to slip too much, I > JRA> concur, do 2.1 and put off the 3.0 stuff till 3.0. (I > JRA> forget: is the announcment list stuff in (the current) 2.1?) > > Which announcement list stuff? Do you mean personalized lists? Yup, > that's in 2.1. Was there more that needed to be done for > "announcement lists"? I meant bulk-mail lists, and I no longer remember what was in my way. More later. 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 804 5015 "So easy to use, no wonder the Internet is going to hell!" -- me From barry@zope.com Wed Aug 29 19:37:20 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 29 Aug 2001 14:37:20 -0400 Subject: [Mailman-Developers] Fw: Re: [Mailman-Users] Digest Problems References: <20010829005638.6fa35c3b.ricardo@rixhq.nu> Message-ID: <15245.13920.692144.911071@anthem.wooz.org> >>>>> "RFK" == Ricardo F Kustner writes: RFK> I just saw this post on the mailman-users list... Good, thanks for forwarding it! I'm hopelessly behind on mailman-users. ;/ RFK> it seems that you can easily break mailman by improperly RFK> using '%' chars in the digest footer... RFK> has this issue been addressed before? will this still happen RFK> in 2.0.6 and 2.1a ? I can imagine that in large mailman RFK> installations, with many different lists and listadmins, this RFK> could cause problems... Both are semi-vulnerable. In the specific situation where you've got something like "30-70%" in the footer, Mailman /should/ catch this and simply append something like "[INVALID FOOTER]". However, there are other ways to break this with stray %'s. Python may raise either a ValueError or a TypeError in these situations, but both Mailman versions are only catching ValueError. E.g. put this in your footer: "Something %else entirely" Blammo. Uncaught TypeError. -Barry From barry@zope.com Wed Aug 29 22:20:59 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 29 Aug 2001 17:20:59 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] * Mailman Docs Moving * References: <5.1.0.14.2.20010828120056.0287ba58@mail.aurora.edu> <17921.999021273@kanga.nu> Message-ID: <15245.23739.5142.926116@anthem.wooz.org> >>>>> "JCL" == J C Lawrence writes: >> Hello everyone. I will be changing jobs this week and the >> mailman documentation will be moving with me. I will be >> looking through my logs to see if I can find people who have >> incoming links but things will be busy for me the next couple >> of days and I may note be able to contact people in a timely >> fashion; so if you link to the docs at >> www.aurora.edu/~ckolar/mailman please note that they will now >> be at: >> www.imsa.edu/~ckolar/mailman JCL> Would there be a problem with putting them directly on the JCL> Mailman site? We could, that's up to Chris. Ideally though, I'd love to have a canonical set of documentation in a GNU blessed format, probably texinfo. -Barry From barry@zope.com Wed Aug 29 22:24:39 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 29 Aug 2001 17:24:39 -0400 Subject: [Mailman-Developers] Re: =?iso-8859-1?Q?handle=5Fopts=2Epy?= References: <3B691C6A000063DB@hawk.dcu.ie> Message-ID: <15245.23959.722185.136904@anthem.wooz.org> >>>>> "d" == donal writes: d> I'm currently messing about with adding some LDAP functionality d> to mailman and need a kick in the right direction. d> I'm working with Mailman-2.0.2 (don't ask!!), and have modified d> handle_opts.py to not mail out a password if the user is stored d> in LDAP (this is if the user clicks the "email me my password" d> button on the subscription page). I've tried to compile the d> code so that I get a handle_opts binary, but everytime i d> compile it the added functionality doesn't appear. I'll just briefly mention that this should be much easier in MM2.1 :). d> I'm compiling by doing a make in the mailman-2.0.2 folder (ie d> the root of the source) and the binary ends up in d> mailman-2.0.2/src. i'm *not* doing a make install - don't want d> the installation overwritten just yet! d> Is there a quicker and easier way to recompile the handle_opts d> binary and any ideas why the functionality i'm adding isn't d> appearing after compilation... You shouldn't need to recompile the binary, which is just a small C wrapper that, through a little bit of -Dmacro magic gets compiled to run Mailman/Cgi/handle_opts.py. Thus you could just do a make install in Mailman/Cgi, although the .pyc files won't get compiled until you actually hit the page (could mess with permissions a bit). Alternatively, and what I do, is have a completely separate second installation for all my testing and development. -Barry From ricardo@rixhq.nu Wed Aug 29 22:36:24 2001 From: ricardo@rixhq.nu (Ricardo F. Kustner) Date: Wed, 29 Aug 2001 23:36:24 +0200 Subject: [Mailman-Developers] Re: [Mailman-Users] * Mailman Docs Moving * In-Reply-To: <15245.23739.5142.926116@anthem.wooz.org> References: <5.1.0.14.2.20010828120056.0287ba58@mail.aurora.edu> <17921.999021273@kanga.nu> <15245.23739.5142.926116@anthem.wooz.org> Message-ID: <20010829233624.1464ab9a.ricardo@rixhq.nu> On Wed, 29 Aug 2001 17:20:59 -0400 barry@zope.com (Barry A. Warsaw) wrote: > >>>>> "JCL" == J C Lawrence writes: > >> www.imsa.edu/~ckolar/mailman > JCL> Would there be a problem with putting them directly on the > JCL> Mailman site? > We could, that's up to Chris. Ideally though, I'd love to have a > canonical set of documentation in a GNU blessed format, probably > texinfo. This reminds me about something I've been thinking about lately... what about having some sort of (GNU blessed? :)) dynamic FAQ system on the Mailman site? There are so many questions which popup regularly on mailman-users that it would safe a lot of questions if we can keep a regularly updated FAQ maintainted by more people... (ie Faq-o-matic or something simular...?) Regards, Ricardo From barry@zope.com Wed Aug 29 22:40:46 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 29 Aug 2001 17:40:46 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] * Mailman Docs Moving * References: <5.1.0.14.2.20010828120056.0287ba58@mail.aurora.edu> <17921.999021273@kanga.nu> <15245.23739.5142.926116@anthem.wooz.org> <20010829233624.1464ab9a.ricardo@rixhq.nu> Message-ID: <15245.24926.343859.282319@anthem.wooz.org> >>>>> "RFK" == Ricardo F Kustner writes: RFK> This reminds me about something I've been thinking about RFK> lately... what about having some sort of (GNU blessed? :)) RFK> dynamic FAQ system on the Mailman site? There are so many RFK> questions which popup regularly on mailman-users that it RFK> would safe a lot of questions if we can keep a regularly RFK> updated FAQ maintainted by more people... (ie Faq-o-matic or RFK> something simular...?) It would probably be easy to take Python's FAQ wizard (in the Python source distro under Tools/faqwiz) and clone it for Mailman's use. I'm not sure where to do that though. The most convenient place for me would probably be on www.python.org, but that may not be the most logical. I'm Cc'ing John Viega to see if it makes sense to run it on list.org, maybe as faq.list.org? -Barry From barry@zope.com Wed Aug 29 23:18:35 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 29 Aug 2001 18:18:35 -0400 Subject: [Mailman-Developers] Handling Bouncebacks References: <15235.8387.111752.64868@anthem.wooz.org> <381104468.998828547@athyra> Message-ID: <15245.27195.233526.400768@anthem.wooz.org> >>>>> "CG" == Carson Gaspar writes: >> The extensible bounce detection subsystem is implemented as >> modules in Mailman/Bouncers, with >> Mailman/Bouncers/BouncerAPI.py as the main entry point. >> Specifically, the function BouncerAPI.ScanMessages() is handed >> the message and the MailList instance. It returns 1 if a >> bounce was detected and registered, and 0 if not. CG> Is it still this broken in 2.1? I thought you were going to CG> add an "I parsed the bounce, and it was non-fatal, so please CG> ignore it" return code. Right now, I either get swamped with CG> non-fatals to -admin, or I unsub users for transient CG> errors. Blech. Okay, I just did. A bouncer module can return Mailman.BouncerAPI.Stop to stop the bounce detector's pipeline, without doing a RegisterBounce(). This effectively supports non-fatal bounce detection with discarding. However, none of the bounce detector modules currently distinguish between temporary and permanent failures. Contributions are welcome. :) -Barry From ricardo@rixhq.nu Wed Aug 29 23:39:17 2001 From: ricardo@rixhq.nu (Ricardo F. Kustner) Date: Thu, 30 Aug 2001 00:39:17 +0200 Subject: [Mailman-Developers] Re: [Mailman-Users] * Mailman Docs Moving * In-Reply-To: <15245.24926.343859.282319@anthem.wooz.org> References: <5.1.0.14.2.20010828120056.0287ba58@mail.aurora.edu> <17921.999021273@kanga.nu> <15245.23739.5142.926116@anthem.wooz.org> <20010829233624.1464ab9a.ricardo@rixhq.nu> <15245.24926.343859.282319@anthem.wooz.org> Message-ID: <20010830003917.2c61876f.ricardo@rixhq.nu> On Wed, 29 Aug 2001 17:40:46 -0400 barry@zope.com (Barry A. Warsaw) wrote: > >>>>> "RFK" == Ricardo F Kustner writes: > RFK> This reminds me about something I've been thinking about > RFK> lately... what about having some sort of (GNU blessed? :)) > RFK> dynamic FAQ system on the Mailman site? > It would probably be easy to take Python's FAQ wizard (in the Python > source distro under Tools/faqwiz) and clone it for Mailman's use. I'm > not sure where to do that though. The most convenient place for me > would probably be on www.python.org, but that may not be the most > logical. I just tested it out... it looks like very usefull; simple yet effective... it uses RCS for versioning and you don't need a Database... Regards, Ricardo. -- "The above message has been blocked because the content was deemed to be unsuitable." -- IMAdmin@*****.co.uk From alaric@babcom.com Wed Aug 29 23:47:10 2001 From: alaric@babcom.com (Phil Stracchino) Date: Wed, 29 Aug 2001 15:47:10 -0700 Subject: [Mailman-Developers] Re: [Mailman-Users] * Mailman Docs Moving * In-Reply-To: <15245.23739.5142.926116@anthem.wooz.org>; from barry@zope.com on Wed, Aug 29, 2001 at 05:20:59PM -0400 References: <5.1.0.14.2.20010828120056.0287ba58@mail.aurora.edu> <17921.999021273@kanga.nu> <15245.23739.5142.926116@anthem.wooz.org> Message-ID: <20010829154710.B4932@babylon5.babcom.com> On Wed, Aug 29, 2001 at 05:20:59PM -0400, Barry A. Warsaw wrote: > We could, that's up to Chris. Ideally though, I'd love to have a > canonical set of documentation in a GNU blessed format, probably > texinfo. Does anyone know of a texi2man tool? I know that texi2html exists. (Personally, I detest the info format and the move from man to info. The man format was simple, lightweight and easy to use, whereas info is cryptic and complex. I've always wondered whether there was any technical reason behind the info system, or whether it was just Stallman's desire to leverage emacs into everything he could possibly shoehorn it into. And personally, I care little for what he blesses -- the man has gone from being the leader of the solution to being part of the problem.) () -- Linux Now! ..........Because friends don't let friends use Microsoft. phil stracchino -- the renaissance man -- mystic zen biker geek alaric@babcom.com halmayne@sourceforge.net 2000 CBR929RR, 1991 VFR750F3 (foully murdered), 1986 VF500F (sold) From che@debian.org Thu Aug 30 00:28:19 2001 From: che@debian.org (Ben Gertzfield) Date: Thu, 30 Aug 2001 08:28:19 +0900 Subject: [Mailman-Developers] [PATCH] Modifying #! env python line to match --with-python In-Reply-To: <15245.9885.712218.961251@anthem.wooz.org> (barry@zope.com's message of "Wed, 29 Aug 2001 13:30:05 -0400") References: <87itf88yxu.fsf@nausicaa.interq.or.jp> <15245.9885.712218.961251@anthem.wooz.org> Message-ID: <878zg2jvjg.fsf@nausicaa.interq.or.jp> >>>>> "BAW" == Barry A Warsaw writes: BAW> This is the primary reason why I don't want to apply the BAW> patch. It's much less pain IMO to add a little shell script BAW> called "python" somewhere earlier in your path than /usr/bin. BAW> That's the whole reason why python is called through BAW> /usr/bin/env. I understand that it can be inconvenient to BAW> hack your $path, but it is less than the pain of trying to BAW> retain the CVS history of those files through the SF BAW> repository. The problem is that BOTH python AND python2 can and are installed on a Debian system, and 'python' will be python 1.x. You can't edit $path for every user possible who will run anything mailman related.. This patch is pretty necessary. You can do the changes by hand, though. All I did was: find mailman -type f -print0 | xargs -0 grep -H '#!.*env.*python' > list to see which files needed to be changed, and then used that list after editing it for sanity: for i in `cat list`; do; \ mv $i $i.in; \ perl -pi.old -e 's/(#!.*env).*python/$! \@PYTHON\@/' $i.in; \ done That was most of the patch. The rest (the Makefile and configure.in changes) are pretty small, and I can send you a smaller patch containing just that if you'd like. I agree, though, I wouldn't be comfortable applying such a large patch myself. Ben -- Brought to you by the letters Q and N and the number 16. "You should be glad you don't have diaper rash. Mah Jongg." Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From barry@zope.com Thu Aug 30 04:30:51 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 29 Aug 2001 23:30:51 -0400 Subject: [Mailman-Developers] [PATCH] Modifying #! env python line to match --with-python References: <87itf88yxu.fsf@nausicaa.interq.or.jp> <15245.9885.712218.961251@anthem.wooz.org> <878zg2jvjg.fsf@nausicaa.interq.or.jp> Message-ID: <15245.45931.522150.376982@anthem.wooz.org> >>>>> "BG" == Ben Gertzfield writes: BG> The problem is that BOTH python AND python2 can and are BG> installed on a Debian system, and 'python' will be python 1.x. Sure, I understand. BG> You can't edit $path for every user possible who will run BG> anything mailman related.. This patch is pretty necessary. How many people do you expect to be using the command line interface for Mailman? BG> You can do the changes by hand, though. I know it's easy to change those files, but what I don't want to do is lose the CVS history of the files. If CVS had a "move" or "copy" command, we'd be fine. If I could hack directly on the repository myself, we'd be fine. Otherwise, it's just too much of a hassle (and too fragile) to preserve the history of the files /and/ try to instruct the SF admins on the necessary repository surgery. Also, from what I understand, now that Python's licensing problems are all cleared up, Debian plans to make Python 2.1.1 the default. -Barry From Dan Mick Thu Aug 30 04:40:36 2001 From: Dan Mick (Dan Mick) Date: Wed, 29 Aug 2001 20:40:36 -0700 (PDT) Subject: [Mailman-Developers] [PATCH] Modifying #! env python line to match --with-python Message-ID: <200108300340.UAA17269@utopia.West.Sun.COM> > I know it's easy to change those files, but what I don't want to do is > lose the CVS history of the files. If CVS had a "move" or "copy" > command, we'd be fine. It doesn't? Man, that bites. From barry@zope.com Thu Aug 30 04:44:12 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 29 Aug 2001 23:44:12 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] * Mailman Docs Moving * References: <5.1.0.14.2.20010828120056.0287ba58@mail.aurora.edu> <17921.999021273@kanga.nu> <15245.23739.5142.926116@anthem.wooz.org> <20010829154710.B4932@babylon5.babcom.com> Message-ID: <15245.46732.931594.9445@anthem.wooz.org> >>>>> "PS" == Phil Stracchino writes: PS> Does anyone know of a texi2man tool? I know that texi2html PS> exists. I'm not aware of one, but I'm Cc'ing Fred Drake, who knows everything there is to know about documentation. :) PS> (Personally, I detest the info format and the move from man to PS> info. The man format was simple, lightweight and easy to use, PS> whereas info is cryptic and complex. I've always wondered PS> whether there was any technical reason behind the info system, PS> or whether it was just Stallman's desire to leverage emacs PS> into everything he could possibly shoehorn it into. And PS> personally, I care little for what he blesses -- the man has PS> gone from being the leader of the solution to being part of PS> the problem.) Leaving politics aside, what I like about texinfo (or latex as with the Python documentation) is that you can write it with any text editor/word processor in the world. That means that anybody can contribute documentation. It's also fairly easy to generate PostScript for hardcopy, or HTML for online browsing, among other formats. The toolchain is widely available and stable. And there's enough semantic and structural markup so that it shouldn't be hard to convert it to the document format du jour (e.g. DocBook, but I could be blowing it out my ass on that one ;). I really like how the Python documentation is done. It has way more than we need for Mailman so I'm not suggesting it. I'm trying to avoid the endless religious arguments about documentation format by just saying texinfo is Good Enough, I have a lot of experience writing stuff in it, and it should be easy enough to learn for anybody who can contribute. As for man pages, I don't disagree that they're damn useful. I /would/ like to see man pages for all the bin/* scripts, but that's just a tiny fraction of the potentially useful Mailman documentation we could provide. And I don't think the description of system use from -- 1) the user's point of view; 2) the list owner/moderator's point of view; 3) the site administrators point of view -- would be well served by man page format. -Barry From barry@zope.com Thu Aug 30 05:05:05 2001 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 30 Aug 2001 00:05:05 -0400 Subject: [Mailman-Developers] Preferred Feedback Pipeline References: <5.1.0.14.0.20010823121154.00ac45c0@mail.ocentrix.com> Message-ID: <15245.47985.262205.540263@anthem.wooz.org> >>>>> "BB" == Ben Burnett writes: BB> Hey Barry, Hey Ben! BB> I'm posting this on the list because I think it would be BB> relevant for everyone to know. BB> What is you're preferred pipeline for feedback on Mailman, BB> especially feedback on testing the development releases? The BB> reason I ask is that it seems that there are quite a few BB> different places that could be used. | The sourceforge site. | bugs, patches, feature requests | http://www.sourceforge.net/projects/mailman | The discussion lists. | much and many of everything. | mailman-users@python.org, mailman-developers@python.org | The wiki. | requirements, architectural directions, component designs, more | http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/FrontPage BB> Did I miss any? That's about got it. BB> Perhaps you'd prefer a different venue and format for BB> different types of feedback. While I don't expect to be able BB> to have 100% of all feedback redirected perhaps if we put your BB> preferred methods in the FAQ, README, and the devs.html, BB> bugs.html, and todo.html pages of the Mailman site a good BB> portion could be redirected. | feature request: sourceforge? | bug report: sourceforge? | patches: sourceforge? | usage questions: mailman-users? | development questions: mailman-developers, wiki? | praise: ? | rant's, demands, whining: /dev/null? | money: ? BB> Am I making an issue out of a non-issue? Here's how it currently works. Occasionally individuals will send me email directly if they notice a small bug or typo. This is probably the most dangerous way to report problems because it's easy for them to get buried in my inbox. You can increase the chances of me seeing it by putting "Mailman" in the subject though. :) For problems with the current development version (i.e. 2.1 alphas), mailman-developers is probably the best place to report them. I've been bad about killing off SF bugs and patches, but intend to do a thorough sweep before 2.1beta1 and during the beta cycle. Once 2.1 goes beta, then I think SF is a valid place to report bugs. For most patches, SF is definitely the way to go. Please try not to post either patches or bugs anonymously (not logged in), because if we need to have a conversation about it, it's very inconvenient to reach you unless you've posted the bug/patch while logged in. Simple feature requests can be discussed on mailman-developers, and probably eventually logged into SF. I'd like to migrate away from the TODO file (aka todo.html), it's too unweildy and doesn't allow that nice conversational rhythm to develop. However, so far we haven't taken much advantage of the SF feature request tracker. The wiki is probably the best place to capture more elaborate design proposals and issues. If we need to discuss, we can move to mailman-developers, but we should probably capture them back in the wiki eventually. I'd like to use the wiki for roadmaps and other longer term design and architectural documentation. Usage questions, mailman-users please. I must regretfully admit that I don't get to read much of mailman-users. I tend to drop in and out depending on how much other stuff I have to do, and it's the first stuff that I give up on and scoot off to a backwater inbox. I'm hoping and trusting you guys to bring important mailman-user issues to my attention. Rants, whinings, demands: Tim Peters . All offers of money, both large and small, of any denomination and national guarantor, or renumeration in kind (tasty beer the more ethnic the better, fast cars, new houses, 2GHz Pentiums running dual-headed 18" flat panels) can be sent directly to me, but only if it's shiny, crisp, roomy, foamy, or speedy. :) Plug: serious interest in funding more focussed work on or with Mailman, through Zope Corporation is welcome. It worked great IMO recently with Control.com and it can work for your mega-$$$ corporation too! :) Let's see, have I missed anything? Well, it does seem a bit fractured. But, other than me being the bottleneck, is the system really broken? -Barry From barry@zope.com Thu Aug 30 05:32:44 2001 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 30 Aug 2001 00:32:44 -0400 Subject: [Mailman-Developers] [PATCH] Modifying #! env python line to match --with-python References: <200108300340.UAA17269@utopia.West.Sun.COM> Message-ID: <15245.49644.537645.599461@anthem.wooz.org> >>>>> "DM" == Dan Mick writes: >> I know it's easy to change those files, but what I don't want >> to do is lose the CVS history of the files. If CVS had a >> "move" or "copy" command, we'd be fine. DM> It doesn't? Not unless it's been added in some spankin' new version that I'm not aware of. It's definitely my #1 gripe with CVS, shared by just about everyone I know. DM> Man, that bites. Indeed. Subversion is supposed to (eventually) lead us to enlightenment. I paraphrase Greg Wilson at IPC8 who said something like "CVS is the worst tool everybody uses". -Barry From salonenp@scc-fl.com Thu Aug 30 06:04:11 2001 From: salonenp@scc-fl.com (Paivi Salonen) Date: Thu, 30 Aug 2001 01:04:11 -0400 Subject: [Mailman-Developers] customizing the listinfo page Message-ID: hello has anyone modified the listinfo page to show all the lists so that the = users can subscribe to as many lists as they want with one signup? = example: http://e-newsletters.internet.com/discussionlists.html. the = individual pages could still be there as they are now. i have looked at the source but i am 100% lost when it comes to python. = and my boss wants it to work that way or we have to use something else.. i = like mailman a lot and i dont want to give up. so.. anyone done this? or anyone willing to give it a try? paivi From tollef@add.no Thu Aug 30 07:37:13 2001 From: tollef@add.no (Tollef Fog Heen) Date: 30 Aug 2001 08:37:13 +0200 Subject: [Mailman-Developers] Mailman man pages (was: Mailman Docs Moving) In-Reply-To: <15245.46732.931594.9445@anthem.wooz.org> References: <5.1.0.14.2.20010828120056.0287ba58@mail.aurora.edu> <17921.999021273@kanga.nu> <15245.23739.5142.926116@anthem.wooz.org> <20010829154710.B4932@babylon5.babcom.com> <15245.46732.931594.9445@anthem.wooz.org> Message-ID: <87ae0ixdd2.fsf_-_@arabella.intern.opera.no> * (Barry A. Warsaw) | As for man pages, I don't disagree that they're damn useful. I | /would/ like to see man pages for all the bin/* scripts, but that's | just a tiny fraction of the potentially useful Mailman documentation | we could provide. I think I have forgotten to mention that I wrote those a little time ago for Debian. Available as a .tgz on http://samfundet.no/~tfheen/mm_manpages.tgz Beware that they uncompress into the current directory, not a subdir. -- Tollef Fog Heen You Can't Win From jeb@ocha.net Thu Aug 30 08:46:39 2001 From: jeb@ocha.net (Jeb Bateman) Date: Thu, 30 Aug 2001 00:46:39 -0700 Subject: [Mailman-Developers] Versions (was: Preventing spam to list admins.) In-Reply-To: <15244.23282.543425.101991@anthem.wooz.org>; from barry@zope.com on Tue, Aug 28, 2001 at 11:01:06PM -0400 References: <9128.998980423@kanga.nu> <15243.59309.332105.36233@anthem.wooz.org> <19975.999027868@kanga.nu> <15244.162.482384.976795@anthem.wooz.org> <24249.999053368@kanga.nu> <15244.23282.543425.101991@anthem.wooz.org> Message-ID: <20010830004639.A1128@ocha.net> On Tue, Aug 28, 2001 at 11:01:06PM -0400, Barry A. Warsaw wrote: > I really really really want to get the next release out as soon as > possible. I don't want a decision to call this thing MM3.0 to mean a > delay in the release schedule. But truth-in-advertising makes me > think it really should be called 3.0. OTOH, will that deter too many > people from upgrading? Sigh, I don't know. Opinions? Would it would be feasible to create a new CVS branch for 2.1, starting from the latest 2.0.x release, and merge important changes from the current development branch into it?? Then the current development branch would indeed become 3.0, sometime ;-) Perhaps 2.1 could be pushed out more quickly this way, with only bug fixes, and non-disruptive features such as the new patch to optionally suppress duplicate messages (which I read was once implemented by the original Mailman author but was lost in a hard disk crash long ago). I remember reading on the wiki the main feature advertised for 3.0 was a site wide user database, to hold one password per user. For 2.1 I could live without the long running qrunner, and the new aliases and role hacks; which could be potentially disruptive to upgrades... Also a quick bug report... Email addresses are case sensitive when sending out password reminders in v2.0. If someone is subscribed as john@doe.org on one list, and John@Doe.org on another, he will get two reminder messages from the same host, since Mailman considers these to be different subscriber addresses. I will try to fix it and create a patch for 2.0.x, unless this behavior is intentional for some reason? Thanks, -jeb From alaric@babcom.com Thu Aug 30 09:17:51 2001 From: alaric@babcom.com (Phil Stracchino) Date: Thu, 30 Aug 2001 01:17:51 -0700 Subject: [Mailman-Developers] Re: [Mailman-Users] * Mailman Docs Moving * In-Reply-To: <15245.46732.931594.9445@anthem.wooz.org>; from barry@zope.com on Wed, Aug 29, 2001 at 11:44:12PM -0400 References: <5.1.0.14.2.20010828120056.0287ba58@mail.aurora.edu> <17921.999021273@kanga.nu> <15245.23739.5142.926116@anthem.wooz.org> <20010829154710.B4932@babylon5.babcom.com> <15245.46732.931594.9445@anthem.wooz.org> Message-ID: <20010830011751.A21264@babylon5.babcom.com> On Wed, Aug 29, 2001 at 11:44:12PM -0400, Barry A. Warsaw wrote: > Leaving politics aside, what I like about texinfo (or latex as with > the Python documentation) is that you can write it with any text > editor/word processor in the world. Actually, I went off half-cocked and confused info with texinfo. Mea culpa. Texinfo is a useful and very flexible format, yes, though I do note that the texinfo distribution seems to include only a very limited selection of texi-to-end-format output tools, and most of the others that you'd epect should exist -- the texi2man tool I've been looking for, to name but one example -- seem very hard to find. (I still think that as a replacement for man, the info browser is a horrible tool ... but that's a completely separate issue from the merits of texinfo.) -- Linux Now! ..........Because friends don't let friends use Microsoft. phil stracchino -- the renaissance man -- mystic zen biker geek alaric@babcom.com halmayne@sourceforge.net 2000 CBR929RR, 1991 VFR750F3 (foully murdered), 1986 VF500F (sold) From che@debian.org Thu Aug 30 09:34:33 2001 From: che@debian.org (Ben Gertzfield) Date: Thu, 30 Aug 2001 17:34:33 +0900 Subject: [Mailman-Developers] [PATCH] Modifying #! env python line to match --with-python In-Reply-To: <15245.45931.522150.376982@anthem.wooz.org> (barry@zope.com's message of "Wed, 29 Aug 2001 23:30:51 -0400") References: <87itf88yxu.fsf@nausicaa.interq.or.jp> <15245.9885.712218.961251@anthem.wooz.org> <878zg2jvjg.fsf@nausicaa.interq.or.jp> <15245.45931.522150.376982@anthem.wooz.org> Message-ID: <878zg29c9y.fsf@nausicaa.interq.or.jp> >>>>> "BAW" == Barry A Warsaw writes: >>>>> "BG" == Ben Gertzfield writes: BG> You can't edit $path for every user possible who will run BG> anything mailman related.. This patch is pretty necessary. BAW> How many people do you expect to be using the command line BAW> interface for Mailman? Every admin who needs to add a list, and every CGI script that needs to do list maintainance. Also, the build process runs lots of command line scripts, which fail if python is not called python. Basically, it's a huge hack for every Debian user to have to make a /usr/local/bin/mailman script and set $path just for mailman.. I think this is not the right solution. BAW> I know it's easy to change those files, but what I don't want BAW> to do is lose the CVS history of the files. If CVS had a BAW> "move" or "copy" command, we'd be fine. If I could hack BAW> directly on the repository myself, we'd be fine. Otherwise, BAW> it's just too much of a hassle (and too fragile) to preserve BAW> the history of the files /and/ try to instruct the SF admins BAW> on the necessary repository surgery. Here's an alternate solution, then. We'll keep the files with their current names, but change #! /usr/bin/env python to #!/usr/bin/env @PYTHON@. Then, instead of using bin/script.in to create bin/script, we'll use the following autoconf feature: Create an empty build directory, say, build/bin/, and call AC_OUTPUT like this. AC_OUTPUT(build/bin/script:bin/script, build/foo/bar:foo/bar) et cetera. That way, we can keep the old names for the scripts, as well as their CVS logs, but we just output the macro-expanded versions under a directory tree that starts with build/ . Is that a good enough solution? I'm extremely interested in getting this to work. I can send a much smaller patch that implements this, if you'd like. BAW> Also, from what I understand, now that Python's licensing BAW> problems are all cleared up, Debian plans to make Python BAW> 2.1.1 the default. This may be, but a lot of people need Python 2.x on existing distributions; in order to do that, python2 must co-exist with python. I really think the above solution is the happy medium; nobody needs to know weird .in names, and the CVS logs are safe. Please let me know what you think. Ben -- Brought to you by the letters X and R and the number 1. "You should be glad you don't have diaper rash. Mah Jongg." Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From mlogemann@morelogs.de Thu Aug 30 10:55:16 2001 From: mlogemann@morelogs.de (Marc Logemann) Date: Thu, 30 Aug 2001 11:55:16 +0200 Subject: [Mailman-Developers] Re: handle_opts.py Message-ID: > You shouldn't need to recompile the binary, which is just a small C > wrapper that, through a little bit of -Dmacro magic gets compiled to > run Mailman/Cgi/handle_opts.py. Thus you could just do a make install > in Mailman/Cgi, although the .pyc files won't get compiled until you > actually hit the page (could mess with permissions a bit). i recently looked over the "subscribe.py" because of the html outputs (allready discussed that), and i had some problems to understand the meaning of the binary files. Up until now, i thought the function were in the binary, but later (of course after struggling with make install) i realized that its enough to edit the subscribe.py in order to have the changes. two basic questions: 1. the binary is only a wrapper w/o any functionality, so its basically only a redirector for the .pyc files? And i assume you use them for some kind of security reasons? 2. Does this mean that normally you dont have to struggle with the binary files? Or are there frequent needs to compile them after changes? Thx for info, i am quite new to python (programmed java and php the last t= wo years) and this compile in mailman/python thing was a miracle to me...I hope i ca= n contribute to mailman, its a nice piece of software. morelogs | Marc Logemann, chief evangelist ____________________________________________________________ Rellinghauser Str. 332 =B7 D-45136 Essen =B7 Germany T: +49 201 84 188-177 =B7 F: +49 201 84 188-199 mlogemann@morelogs.de =B7 http://www.morelogs.de From donal.hunt2@mail.dcu.ie Thu Aug 30 15:15:01 2001 From: donal.hunt2@mail.dcu.ie (donal.hunt2@mail.dcu.ie) Date: Thu, 30 Aug 2001 15:15:01 +0100 Subject: [Mailman-Developers] =?iso-8859-1?Q?Re=3A=20=5BMailman=2DDevelopers=5D=20Re=3A=20handle=5Fopts=2Epy?= Message-ID: <3B691C6A000070FD@hawk.dcu.ie> Marc, It's enough to just edit the *.py files afaik. When the file is next use= d by Mailman it will be recompiled into its *.pyc version. The files in ~m= ailman/cgi-bin are just wrappers for the *.pyc files in ~mailman/Mailman/Cgi Confusing at first, but very nice for maintenance and coding in new featu= res. :) Thanks again for the pointers Barry... Donal ----------------------------------------------------------------------- Message: 12 Date: Thu, 30 Aug 2001 11:55:16 +0200 From: Marc Logemann To: mailman-developers@python.org Subject: Re: [Mailman-Developers] Re: handle_opts.py > You shouldn't need to recompile the binary, which is just a small C > wrapper that, through a little bit of -Dmacro magic gets compiled to > run Mailman/Cgi/handle_opts.py. Thus you could just do a make install > in Mailman/Cgi, although the .pyc files won't get compiled until you > actually hit the page (could mess with permissions a bit). i recently looked over the "subscribe.py" because of the html outputs (allready discussed that), and i had some problems to understand the meaning of the binary files. Up until now, i thought the function were in the binary, but later (of course after struggling with make install) i realized that its enough to edit the subscribe.py in order to have the changes. two basic questions: 1. the binary is only a wrapper w/o any functionality, so its basically only a redirector for the .pyc files? And i assume you use them for some kind of security reasons? 2. Does this mean that normally you dont have to struggle with the binary= files? Or are there frequent needs to compile them after changes? Thx for info, i am quite new to python (programmed java and php the last t=3D wo years) and this compile in mailman/python thing was a miracle to me...I hope i ca=3D n contribute to mailman, its a nice piece of software. morelogs | Marc Logemann, chief evangelist ____________________________________________________________ Rellinghauser Str. 332 =3DB7 D-45136 Essen =3DB7 Germany T: +49 201 84 188-177 =3DB7 F: +49 201 84 188-199 mlogemann@morelogs.de =3DB7 http://www.morelogs.de From nb@thinkcoach.com Thu Aug 30 15:32:13 2001 From: nb@thinkcoach.com (Norbert Bollow) Date: Thu, 30 Aug 2001 16:32:13 +0200 Subject: [Mailman-Developers] sendmail In-Reply-To: (message from Harold Paulson on Wed, 29 Aug 2001 10:53:43 -0700) References: Message-ID: <200108301432.f7UEWDi04292@quill.local> Chuq Von Rospach wrote: > > I did this a little differently, since I know that tweaking sendmail.cf > files gives many people hives, and so people aren't likely to do it. It's > also unneccesary. > > You can do this without modifying your sendmail files at all. Instead, in > your startup script, add: > > /usr/sbin/sendmail -bd -ODeliveryMode=defer \ > -ODaemonPortOptions=Name=MSA,Port=NNNN,M=E,Addr=127.0.0.1 > > Where NNNN is some port number not otherwise used (you can test if > something's in use by doing "telnet localhost NNNN" -- if it's refused, > there's no daemon listening) > > This sets up a sendmail process listening to the alternate port, in DEFER > mode, but set to talk only to the localhost interface, so it's not > accessible by anyone other than your local machine: no open relay problems. Actually, you can't rely on this unless you have checked how your machine's IP implementation works exactly. It says in section 3.3.4.2 of RFC 1122 There are two key requirement issues related to multihoming: (A) A host MAY silently discard an incoming datagram whose destination address does not correspond to the physical interface through which it is received. Yes, that is a "MAY", not a "MUST", not even a "SHOULD". There are TCP/IP stacks out there which allow your 127.0.0.1 interface to be accessed from outside the local machine. Greetings, Norbert. -- A member of FreeDevelopers and the DotGNU Steering Committee: dotgnu.org Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland) Tel +41 1 972 20 59 Fax +41 1 972 20 69 http://thinkcoach.com Your own domain with all your Mailman lists: $15/month http://cisto.com From fdrake@acm.org Thu Aug 30 16:43:30 2001 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 30 Aug 2001 11:43:30 -0400 Subject: [Mailman-Developers] Re: [Mailman-Users] * Mailman Docs Moving * In-Reply-To: <200108300433.f7U4XJX03656@smtp.zope.com> References: <5.1.0.14.2.20010828120056.0287ba58@mail.aurora.edu> <17921.999021273@kanga.nu> <15245.23739.5142.926116@anthem.wooz.org> <20010829154710.B4932@babylon5.babcom.com> <200108300433.f7U4XJX03656@smtp.zope.com> Message-ID: <15246.24354.37609.220668@grendel.digicool.com> Barry A. Warsaw writes: > Leaving politics aside, what I like about texinfo (or latex as with > the Python documentation) is that you can write it with any text > editor/word processor in the world. That means that anybody can That's true for man pages as well, but the markup is a bit more obscure and more presentation-driven than it should be, but that's a minor issue given the heavy use of convention in man pages. > contribute documentation. It's also fairly easy to generate > PostScript for hardcopy, or HTML for online browsing, among other > formats. The toolchain is widely available and stable. And there's This is true for man pages as well; a properly-written & marked man page can have a very nice printed form. > enough semantic and structural markup so that it shouldn't be hard to > convert it to the document format du jour (e.g. DocBook, but I could > be blowing it out my ass on that one ;). I'm standing back! ;-) But this is where Texinfo improves on the troff -man markup; it generally relies less on convention and template-driven authoring to get the job done, so is easier to convert. > I really like how the Python documentation is done. It has way more > than we need for Mailman so I'm not suggesting it. I'm trying to Both more and less, as we've discussed. > avoid the endless religious arguments about documentation format by > just saying texinfo is Good Enough, I have a lot of experience writing > stuff in it, and it should be easy enough to learn for anybody who can > contribute. My keyboard doesn't have an "@" key. ;-) > As for man pages, I don't disagree that they're damn useful. I > /would/ like to see man pages for all the bin/* scripts, but that's > just a tiny fraction of the potentially useful Mailman documentation > we could provide. And I don't think the description of system use > from -- 1) the user's point of view; 2) the list owner/moderator's > point of view; 3) the site administrators point of view -- would be > well served by man page format. I agree. DocBook would solve both the general documentation and man page problem. So go with DocBook like I told you. ;-) Seriously, the common tools for DocBook leave something to be desired, especially for typeset formats. Writting a better tool would not be terribly hard these days, especially if you went with the XML version of DocBook. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From WayneR@strosniders.com Thu Aug 30 18:28:39 2001 From: WayneR@strosniders.com (Wayne Ringling) Date: Thu, 30 Aug 2001 13:28:39 -0400 Subject: [Mailman-Developers] Easy question about 2.1a2 - I hope. Message-ID: <951703DE931CD511A80600A0C9825BAA278E@BETH-EMAIL> I was able to get Mailman 2.1a2 working on my SuSe 7.2 box. I have done some testing and all seems to be working fine. Nice job Barry! I have been customizing the listinfo pages and can't seem to find where I can change the text displayed with . Is there any way to change this info? or is it hard coded into a module. If so then which module, I think I could hack it from there. Also, one other thing, in the README docs that talks about customizing the install, a blurb about how to edit the user interface pages might be a needed addition. I went back into the list archives to learn how to make custom list specific pages. But some users won't go to that extent. TIA Wayne Ringling From liuk@publinet.it Thu Aug 30 18:35:32 2001 From: liuk@publinet.it (Luca Maranzano) Date: Thu, 30 Aug 2001 19:35:32 +0200 Subject: [Mailman-Developers] MM 2.1a2: bug if dont_respond_to_post_requests=N -> lang is undefined Message-ID: <20010830193532.A436@publinet.it> Hi, I've already submitted a bug to SF about this, but I can confirm that if I set dont_respond_to_post_requests to NO then this seems to arise a bug in Hold.py, i.e. the variable lang is not set and I get the following error: Aug 30 16:43:04 2001 (17624) Uncaught runner exception: Local variable 'lang' referenced before assignment Aug 30 16:43:04 2001 (17624) Traceback (most recent call last): File "/home/mailman/Mailman/Queue/IncomingRunner.py", line 134, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/home/mailman/Mailman/Handlers/Hold.py", line 145, in process hold_for_approval(mlist, msg, msgdata, ModeratedPost) File "/home/mailman/Mailman/Handlers/Hold.py", line 277, in hold_for_approval charset=Utils.GetCharSet(lang)) UnboundLocalError: Local variable 'lang' referenced before assignment I think that the patch is quite simple, but I'm not yet able to provide it :) MM 2.1a2. Regards, Luca From nvp@atg.com Thu Aug 30 19:44:08 2001 From: nvp@atg.com (Nathan V. Patwardhan) Date: Thu, 30 Aug 2001 14:44:08 -0400 Subject: [Mailman-Developers] Why no regex for forbidden_posters[] ? Message-ID: <20010830144408.A15760@atg.com> All, I'd hoped that Mailman would let me have "closed" lists in the sense that I could reject anything from outside of 'atg.com'. forbidden_posters[], I figured, was implemented to take a regular expression. Instead, it seems that Utils.py implements FindMatchingAddresses(...), which returns an *exact match* of an address. This isn't the behavior that I'd hoped for, since (a) we're sure to have open lists that are only used internally and (b) So, I guess that I have two questions: 1. What would be wrong with having something like this: # in a list's config forbidden_posters = ['^.*@(?!atg.com$)', 'another_regex_here', 'etc...'] # from Handlers/Hold.py addrs = Utils.FindMatchingAddresses(sender, forbiddens) if addrs: hold_for_approval(mlist, msg, msgdata, ForbiddenPoster) ... def FindMatchingAddresses(sender, forbiddens): res = [] for each_banned in forbiddens: p = re.compile(each_banned) m = p.match(each_banned) if m != None: res.append(each_banned) return res 2. Instead of hold_for_approval(...), would anyone have any objections if a method like kill_forbidden_message(...) was implemented? We have many, many lists and often times a list administrator (the users themselves) won't think to delete messages that are blocked, yet get held for approval. -- Nate Patwardhan Art Technology Group ******************************************** $ ping elvis elvis is alive From barry@zope.com Fri Aug 31 06:34:03 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 31 Aug 2001 01:34:03 -0400 Subject: [Mailman-Developers] MM 2.1a2: bug if dont_respond_to_post_requests=N -> lang is undefined References: <20010830193532.A436@publinet.it> Message-ID: <15247.8651.802863.798688@anthem.wooz.org> >>>>> "LM" == Luca Maranzano writes: LM> I've already submitted a bug to SF about this, but I can LM> confirm that if I set dont_respond_to_post_requests to NO then LM> this seems to arise a bug in Hold.py, i.e. the variable lang LM> is not set and I get the following error: Thanks, but this is already out-of-date w.r.t. cvs :). I've closed the bug, but appreciate your report. -Barry From barry@zope.com Fri Aug 31 06:38:51 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 31 Aug 2001 01:38:51 -0400 Subject: [Mailman-Developers] Easy question about 2.1a2 - I hope. References: <951703DE931CD511A80600A0C9825BAA278E@BETH-EMAIL> Message-ID: <15247.8939.4567.597253@anthem.wooz.org> >>>>> "WR" == Wayne Ringling writes: WR> I was able to get Mailman 2.1a2 working on my SuSe 7.2 box. WR> I have done some testing and all seems to be working fine. WR> Nice job Barry! Thanks! WR> I have been customizing the listinfo pages and can't seem to WR> find where I can change the text displayed with WR> . Is there any way to change this info? WR> or is it hard coded into a module. If so then which module, I WR> think I could hack it from there. It's hard coded into Mailman/Cgi/listinfo.py. The actual replacement is defined in Mailman/HTMLFormatter.py. WR> Also, one other thing, in the README docs that talks about WR> customizing the install, a blurb about how to edit the user WR> interface pages might be a needed addition. I went back into WR> the list archives to learn how to make custom list specific WR> pages. But some users won't go to that extent. Yup, there needs to be some documentation regarding the hierarchical template lookup, but one of the deficiencies is that not every web page is fully templatize. That's a post-2.1 issue. -Barry From liuk@publinet.it Fri Aug 31 12:55:04 2001 From: liuk@publinet.it (Luca Maranzano) Date: Fri, 31 Aug 2001 13:55:04 +0200 Subject: [Mailman-Developers] MM 2.1a2: bug if dont_respond_to_post_requests=N -> lang is undefined In-Reply-To: <15247.8651.802863.798688@anthem.wooz.org> References: <20010830193532.A436@publinet.it> <15247.8651.802863.798688@anthem.wooz.org> Message-ID: <20010831135504.A10140@publinet.it> Hi, Barry, regarding the hang of the browser, I've found the problem: there were many lock files for that mailing list in the locks/ directory (I've killed qrunner with -9 since it was eating 99% CPU). Removing them solved the hang. I'd like to contribute to the testing of the current development release, I've tryed anonymous access to the CVS and it works :). Now my question is: can I simply issue a "configure && make install" in the CVS tree or there are some other action that I must consider? :) TIA. Regards, Luca On Fri, Aug 31, 2001 at 01:34:03AM -0400, Barry A. Warsaw wrote: > > >>>>> "LM" == Luca Maranzano writes: > > LM> I've already submitted a bug to SF about this, but I can > LM> confirm that if I set dont_respond_to_post_requests to NO then > LM> this seems to arise a bug in Hold.py, i.e. the variable lang > LM> is not set and I get the following error: > > Thanks, but this is already out-of-date w.r.t. cvs :). I've closed > the bug, but appreciate your report. > > -Barry From barry@zope.com Fri Aug 31 15:45:04 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 31 Aug 2001 10:45:04 -0400 Subject: [Mailman-Developers] MM 2.1a2: bug if dont_respond_to_post_requests=N -> lang is undefined References: <20010830193532.A436@publinet.it> <15247.8651.802863.798688@anthem.wooz.org> <20010831135504.A10140@publinet.it> Message-ID: <15247.41712.623906.586729@anthem.wooz.org> >>>>> "LM" == Luca Maranzano writes: LM> Barry, regarding the hang of the browser, I've found the LM> problem: there were many lock files for that mailing list in LM> the locks/ directory (I've killed qrunner with -9 since it was LM> eating 99% CPU). Removing them solved the hang. Ah, common problem. LM> I'd like to contribute to the testing of the current LM> development release, I've tryed anonymous access to the CVS LM> and it works :). Yay! :) LM> Now my question is: can I simply issue a "configure && make LM> install" in the CVS tree or there are some other action that I LM> must consider? :) Depends on whether you're upgrading an existing site or testing it out in a separate installation (which I recommend for now). If the latter, then yup that should do it. If you're upgrading over an existing site, then read the instructions in the UPGRADING manual. Part of "testing it out" is also testing that upgrading is as painless (or as documented ) as possible. Thanks, -Barry