Mailman 3 July 2002 - Mailman-Developers

Re: Initial Mailman v2.0 with TMDA and Mime filtering
by Jason R. Mastaler 31 Jul '02

31 Jul '02

J C Lawrence <claw(a)kanga.nu> writes: > I'm also not a QMail user and so can't comment for similar > reasons. I should have a Mailman/TMDA/qmail HOWTO ready shortly. And, it's significantly less complex that what was detailed here. It's based on the dot-qmail interface, and so doesn't require any changes to qmail, doesn't use procmail, etc. Stay tuned. -- (http://tmda.net/)

1 0

[ mailman-Patches-573509 ] ToUsenet: subject prefix stripping
by noreply＠sourceforge.net 31 Jul '02

31 Jul '02

Patches item #573509, was opened at 2002-06-25 02:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=573509&group_i… Category: None Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Mark Weaver (mdw21) Assigned to: Nobody/Anonymous (nobody) Summary: ToUsenet: subject prefix stripping Initial Comment: For some inexplicable reason ToUsenet is trying to -add- the subject prefix. Now this doesn't work generally anyway (consider a plain post - this won't do it). Typically, the subject prefix is the list- name, which just replicates information we already have (as we already know which newsgroup we are looking at). Anyway, arguments aside, I've fixed up ToUsenet.py to go the other way and remove subjects. (I would have made this an option, but my Python is non-existent). ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-31 13:02 Message: Logged In: YES user_id=12800 This is a duplicate of 573508 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=573509&group_i…

1 0

[ mailman-Patches-573508 ] ToUsenet: subject prefix stripping
by noreply＠sourceforge.net 31 Jul '02

31 Jul '02

Patches item #573508, was opened at 2002-06-25 02:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=573508&group_i… >Category: mail delivery >Group: Mailman 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: Mark Weaver (mdw21) Assigned to: Nobody/Anonymous (nobody) Summary: ToUsenet: subject prefix stripping Initial Comment: For some inexplicable reason ToUsenet is trying to -add- the subject prefix. Now this doesn't work generally anyway (consider a plain post - this won't do it). Typically, the subject prefix is the list- name, which just replicates information we already have (as we already know which newsgroup we are looking at). Anyway, arguments aside, I've fixed up ToUsenet.py to go the other way and remove subjects. (I would have made this an option, but my Python is non-existent). ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-07-31 13:01 Message: Logged In: YES user_id=12800 This patch is only relevant to MM2.0, and that version is in critical bug fix phase only. MM2.1 does it differently, but I'm wondering if the subject should not be added to news bound messages either? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=573508&group_i…

1 0

[ mailman-Bugs-588373 ] bug with 2.1b2 (something with cookies?)
by noreply＠sourceforge.net 31 Jul '02

31 Jul '02

Bugs item #588373, was opened at 2002-07-29 23:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=588373&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Marshall (paulmarshll) Assigned to: Nobody/Anonymous (nobody) Summary: bug with 2.1b2 (something with cookies?) Initial Comment: This is hopefully my third and final stupid question involving mailman. I have mailman 2.1b2 setup and mostly working (I can create lists, and post, etc...). However whenever I try to log into a list via the admin page to edit/delete/whatever to it, it comes up with this bug: Traceback (most recent call last): File "/var/mailman/scripts/driver", line 82, in run_main main() File "/var/mailman/Mailman/Cgi/admin.py", line 82, in main cgidata.getvalue('adminpw', '')): File "/var/mailman/Mailman/SecurityManager.py", line 208, in WebAuthenticate print self.MakeCookie(ac, user) File "/var/mailman/Mailman/SecurityManager.py", line 223, in MakeCookie c = Cookie.SimpleCookie() AttributeError: 'module' object has no attribute 'SimpleCookie' Is this a permissions problem? something to do with creating cookies...Honestly, I have no idea... I've searched some bug databases and most likely passed right over it, however I can't seem to find anything dealing with this error. Thanks for all the help. Paul ---------------------------------------------------------------------- >Comment By: Paul Marshall (paulmarshll) Date: 2002-07-31 11:43 Message: Logged In: YES user_id=582441 I fixed the problem. Apparently I still had Cookie.py and Cookie.pyc, which I deleted, this seemed to fix the problem. Found this on: http://mail.python.org/pipermail-21/mailman-developers/2001- November/010020.html Thanks anyways. This post can be deleted. Paul ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=588373&group_i…

1 0

Re: [Mailman-Developers] Cute TMDA use
by J C Lawrence 31 Jul '02

31 Jul '02

On 30 Jul 2002 15:43:52 +0100 Nigel Metheringham <Nigel.Metheringham(a)dev.InTechnology.co.uk> wrote: > An additional thing that would make me very much in favour of TDMA > would be the possibility of adding a message to the confirmation > stating that by posting to this list they are putting their messages > into public archives. If they confirm the message then they have > given permission for archiving. TMDA handles that by making all the confirmation, request etc messages template based, with the template directory having both a default and a CLI switch (eg for per list customisation in our case). > That would mean that all posts to the list are either from subscribers > (who got the information about archiving at time of subscription), or > those that have confirmed their willingness to be archived. Excellent point. I like it. Note however that that implies that subscribers who post have to verify thru TMDA. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

4 12

Re: [Mailman-Developers] Initial Mailman v2.0 with TMDA and Mime filtering
by J C Lawrence 31 Jul '02

31 Jul '02

On Tue, 30 Jul 2002 22:46:45 -0700 J C Lawrence <J> wrote: > On Tue, 30 Jul 2002 22:30:12 -0700 J C Lawrence <J> wrote: >> I'm writing this now as the discussed configuration appears to work >> and I'd rather document it now while its still fresh in my mind then >> later when its not. If any big bugs or required changes surface I'll >> post on those later to the mailman-developers list. > Its now section 6.7 in the mailman user FAQ: > http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.007.htp If you want to play with a list set up this way I still have my list installation running. Give me a shout and I'll send over the addresses etc. Abusers will of course get blacklisted. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

1 0

Re: Opening up a few can o' worms here...
by Ka-Ping Yee 30 Jul '02

30 Jul '02

Barry wrote: > Do you want to attempt to obscure the > address (e.g. "barry--at--python--dot--org") Chuq wrote: > Anything you programmatically obscure will be programmatically > de-obscured. I don't think this is entirely true. This is probably true if you invent ways of rearranging text that is still readable as an e-mail address, but one possible good solution is to use an image instead. If you generate an image containing the entire e-mail address, it can be made extremely hard to read, even with state-of-the-art OCR. And it raises the bar so high that it will be a long time before spammers bother to even try OCR -- it's much too easy to harvest addresses in other, simpler ways. Just to give you an idea of what tricks are possible: a GIF can contain many different colour table entries that map to almost the same colour; the background can be patterned; the text can be distorted or blurred; the text can be drawn shadowed or embossed; the text can be broken into multiple frames of a GIF animation; etc. etc. Many of these things can be done subtly enough that the text is still trivial for anyone to read, yet it becomes phenomenally difficult for a machine to decode -- to the point where the spammer's best bet is to take a video capture of the screen, print it out, run it through a scanner, and run a fancy OCR program on the result. -- ?!ng

8 17

Re: [Mailman-Developers] Cute TMDA use
by Donal Hunt 30 Jul '02

30 Jul '02

mailman-developers-request(a)python.org wrote: ------------------------------------------------------------------------ > Subject: Re: [Mailman-Developers] Cute TMDA use > Date: Mon, 29 Jul 2002 22:29:29 -0400 > From: barry(a)python.org (Barry A. Warsaw) > To: Chuq Von Rospach <chuqui(a)plaidworks.com> > CC: J C Lawrence <claw(a)kanga.nu>, <mailman-developers(a)python.org> > References: <15685.53303.972678.484832(a)anthem.wooz.org> > <B96B225E.4ACED%chuqui(a)plaidworks.com> > > Ah wait, I see what you're suggesting. A confirmed non-member > wouldn't get added to accept_these_nonmembers, but their message would > not show up in the admindb until they've confirmed. > > The messages would be in a sort of limbo until them, with > timeout/auto-discards if they don't confirm after a certain amount of > time. Once they've confirmed, we'll do the normal non-member action > (although it would make little sense to go through this rigamarole if > we're simply discarding or rejecting non-member postings). > > Maybe the admindb should have a button that would let them see all > held message, including non-confirmed ones? Perhaps that's a YAGNI. > > Have I got that right? I'll think on it and try to decide whether > it's worth adding to 2.1 or not. > > -Barry > > ------------------------------------------------------------------------ The above would be great!! We currently have a problem with students (university environment) sending "spam" to hundreds of lists so they can find a room mate!! We've stopped it by reducing the number of lists a person can post to at the same time. However, the side effect is that the list admin (one for all the student lists) gets mailed hundreds of times because there is one pending message for each list!!! So we wrote a script to clear the pending messages log. :) The above would be fierce handy as the list admin wouldn't get mailed about unconfirmed emails until they were confirmed... And if someone got 200+ confirmation mails it's unlikely the messages would ever be seen by the list admin. "This would be a good thing"(tm). :) The central userbase (if it included the admins too) would mean admins would get one email about all the pending messages for their lists and perhaps one webpage for confirming/rejecting (ie multiple list all on the same page / login) would be excellent too. Anyway... that's further down the road - let's keep our eye on the 2.1 ball!! Donal DCU

4 5

Adding exception to html-stripping in the archive
by Laurence Berland 30 Jul '02

30 Jul '02

All, I posted this earlier, but it was sort of buried in an email about not necessarily related things. Here's what I'm trying to do: I've already written code that filters the messages on their way to the archiver, substituting based on regular expressions. It does this in the Queue/ArchRunner.py file, in just about the last spot before the actual archiver gets called. It can't go in the archiver, because it needs to be able to read the mlist variable for configuration and such. I need to be able to use a regular expression to substitute in a snippet of html code. This could be used for several things, but my intention is to use it to add an img tag. Is there a way to configurably get around the html-sanitizing done by the archiver in some non-kludge way? TIA, Laurence

1 0

Re: [Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use)
by J C Lawrence 30 Jul '02

30 Jul '02

On Tue, 30 Jul 2002 11:47:07 -0600 Jason R Mastaler <Jason> wrote: > J C Lawrence <claw(a)kanga.nu> writes: >> Note: SF is likely going to have severe performance problems with the >> current flatfile list implementation. Odds are that they're going to >> want a persistent SQL-backed implementation due to their size. > What flatfile list implementation are you referring to? I failed to noticed the cdb/dbm/etc list code. Ooops. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

1 0

Re: [Mailman-Developers] Re: Opening up a few can o' worms here...
by J C Lawrence 30 Jul '02

30 Jul '02

On Tue, 30 Jul 2002 10:22:39 -0700 Chuq Von Rospach <chuqui(a)plaidworks.com> wrote: > On 7/30/02 10:14 AM, "J C Lawrence" <claw(a)kanga.nu> wrote: >> Building the archives (even if not the list) with dated or sender >> addresses TMDA-style starts seeming quite attractive. > Actually, we're putting everything behind a CGI that'll enforce our > policies. That way, if the policies change, only the CGI has to be > modified, not the archives. And we don't have to modify the archives > -- which is problematic if you take stuff out that later you decide > ought to be there. An unmodified archive is a lot easier to deal > with. Yeah, I get the same end by a MVC abstraction in my (currently) PHP template processing code. The raw PHP file generated by MHonArc is, well, raw. The external globally shared code that does the actual render to HTML etc can re-wrap/re-present etc as desired. (Which is really just making a false distinction between PHP pages using shared code and a CGI). -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

1 0

Re: [Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use)
by J C Lawrence 30 Jul '02

30 Jul '02

On Mon, 29 Jul 2002 20:06:49 -0700 (PDT) Dan Mick <dmick(a)utopia.West.Sun.COM> wrote: > Probably missing something again. But I'm on very few lists that > share a server, so I'd expect the normal behavior of "one confirm per > list per alien address" behavior anyway (I think the only multilist > server I communicate with is python.org). SourceForge is the other canonical case. Note: SF is likely going to have severe performance problems with the current flatfile list implementation. Odds are that they're going to want a persistent SQL-backed implementation due to their size. :nudges Marc. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

2 1

Re: [Mailman-Developers] Re: Opening up a few can o' worms here...
by J C Lawrence 30 Jul '02

30 Jul '02

On Tue, 30 Jul 2002 09:57:47 -0700 Chuq Von Rospach <chuqui(a)plaidworks.com> wrote: > (this is one reason why, for instance, we are reinventing our archive > system to remove the passwords we're currently using to keep the bots > out. Because that's a system that doesn't really solve the problem, > any more than a "do not enter" sign on an unlocked door stops a > burglar. It only stops stupid burglars.) Building the archives (even if not the list) with dated or sender addresses TMDA-style starts seeming quite attractive. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

2 1

Re: [Mailman-Developers] Cute TMDA use
by Donal Hunt 30 Jul '02

30 Jul '02

Dan Mick wrote: > > > The above would be great!! We currently have a problem with students > > (university environment) sending "spam" to hundreds of lists so they can > > find a room mate!! > > ...And note that this is an argument for list-specific (i.e. non-global) > whitelists, as "just because you can post to the alt.magic.i-have-no-life > list doesn't give you the right to post to wedding-planners, just because > they happen to share disk space on the same host cluster". Most definately. Donal DCU

1 0

Re: [Mailman-Developers] Off topic: a cautionary tale.
by J C Lawrence 30 Jul '02

30 Jul '02

On Tue, 30 Jul 2002 08:34:50 -0400 (EDT) Dale Newfield <Dale(a)Newfield.org> wrote: > I've thought for a while that phpMyAdmin was making a mistake with GET > links for all those actions--they should be POST buttons, and spiders > would not be able to do this. It is making a mistake. W3C specs state that only POSTs may have side effects, not GETs. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

1 0

Off topic: a cautionary tale.
by Chuq Von Rospach 30 Jul '02

30 Jul '02

Just because it's too much fun to not pass along, and a useful cautionary tale. Fortunately, the person this happened to has a sense of humor about it... A friend of mine was working on his home web site. It was a bunch of stuff, back-ended by mySQL. He was, for instance, installing a search engine (using htDig) for the content, but it wasn't cooperating and he was trying to figure out why. Suddenly, the site goes dark. He can't log into it. He starts snooping, he can't get into MySQL. Uh, oh. (oh. No backups, either). The entire site implodes. He finally gives up, goes into the web logs to see what happens, thinking he got hacked. Well, not quite. One of the tools he installed was phpMyAdmin to administer the MySQL stuff. He installed it behind a .htaccess file like you're supposed to. But what he didn't realize was the .htaccess file wasn't working right, letting anything in. What got in was -- htDig, the search engine. Which happily follows all links, including, if you let it spider phpMyAdmin, the "delete this database" links. Including the database holding all of the MySQL configuration and account info. Which causes MySQL to die. Which... You get the picture. His search engine got into his database and deleted all of his data, because while it wasn't working, it COULD spider. And it got into an area it shouldn't have gotten into, even though it wasn't linked on the web site. How's that, you ask? How did HtDIG find it? Well -- one of the other things he'd added was log processing. Including referer tracking. And one of the links the logs showed was a referer link back to the phpMyAdmin pages. So by spidering the web log data, HtDIG found a link into phpMyAdmin, which was supposed to be password protected but wasn't, which let htDig become a DBA, which let HtDIG delete all of the data... When you build systems, do you think through the side effects of what you're doing? What are you missing? (and would you have ever figured out why this happened to you? I wonder if I would have.... ) Happy hacking... But be careful out there. -- Chuq Von Rospach, Architech chuqui(a)plaidworks.com -- http://www.chuqui.com/ The Cliff's Notes Cliff's Notes on Hamlet: And they all died happily ever after

3 3

Patch to add general regex filtering module, hooks to archive
by Laurence Berland 30 Jul '02

30 Jul '02

All, I've written and now tested a new Handler module, Filter.py, and I've added the various hooks it needs to filter on messages before they are archived. There are about 70billion different uses for this sort of thing, but the one I'm after is replacing a string (say :1:) with an image tag (say <img src="/icons/green.png">). My two questions are thus: 1. Is there a way to turn off the conversion of < and > to %lt; etc in the archive for a specific list? 2. Where should I submit my patches? They're against a cvs checkout from yesterday afternoon, so likely will patch completely cleanly into the code. Laurence

1 0

Re: [Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use)
by J C Lawrence 30 Jul '02

30 Jul '02

On Mon, 29 Jul 2002 10:47:02 -0600 Jason R Mastaler <Jason> wrote: > J C Lawrence <claw(a)kanga.nu> writes: >> Given that the TMDA python product carries almost all the needed >> payload, I wonder if a TMDA-plugin rooted in the TMDA product doesn't >> make more sense. > I'm comfortable with this as well, and don't mind making modifications > to TMDA that would make this easier if that proves necessary. <nod> Not speaking for Barry, but there are large advantages to leveraging code that other people maintain vs increasing the code and maintenance load of Mailman. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

4 11

[ mailman-Patches-444884 ] Integration of Mailman & htdig for archi
by noreply＠sourceforge.net 30 Jul '02

30 Jul '02

Patches item #444884, was opened at 2001-07-26 18:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444884&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Barrett (ppsys) Assigned to: Nobody/Anonymous (nobody) Summary: Integration of Mailman & htdig for archi Initial Comment: This patch is applicable to Mailman 2.0.6 release that has had search enhancement patch 444879 patch installed - if your Defaults.py has the ARCHIVE_INDEXING_ENABLE and ARCHIVE_INDEXING_DISABLE in it then you've got that patch. It replaces earlier patches 401670 and 402423 and is mainly to correct some problems arising from fixes introduced into Mailman by bug fix releases since the 402423 patch. This patch integrates htdig with Mailman and provides: 1. per list search facility with a search form on the list's TOC page. 2. maintenance of privacy of private archives which requires the user to establish their credentials via the normal private archive access before any access via htdig is allowed. 3. a common base URL for both public and private archive access via htsearch results so that htdig indices are unaffected by changingan archive from private to public and vice versa. All access to archives via htdig is controlled by a new wrapped cgi- bin script called htdig.py. 4. a new cron activated script and extra crontab entry which runs htdig regularly to maintain the per list search indices. 5. automatic creation, deletion and maintenance of htdig configuration files and such. Beyond installing htdig and telling Mailman where it is via mm_cfg you do not have to do any other setup. Well not quite you do have to set up a single per installation symlink to allow htdig to find the automatically generated per list htdig configuration files. You probably want to run this patch as follows: cd <mailman 2.0.6 untarred and unzipped directory> patch -p1 < <this patch file> ---------------------------------------------------------------------- >Comment By: Richard Barrett (ppsys) Date: 2002-07-30 11:25 Message: Logged In: YES user_id=75166 htdig-2.0.13-0.1.patch is purely cosmetic to get no mumble application to MM 2.0.13 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-25 15:07 Message: Logged In: YES user_id=75166 Do not use htdig-2.0.12-0.1.patch there is an error in it. Use htdig-2.0.12-0.2.patch instead ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-25 14:10 Message: Logged In: YES user_id=75166 htdig-2.0.12-0.1.patch is a revised version of the patch that applies without complaint to MM 2.0.12. It also add a facility for adding site wide htdig configuration attributes to all list specific htdig configuration files. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-05-23 09:59 Message: Logged In: YES user_id=75166 htdig-2.0.11-0.1.patch is a revised version of the patch that is compatible with MM 2.0.11 This version removes an incompatibility with Python 2.2 which caused warning messages to be generated when any of the family cron/nightly_htdig scripts were run. Some guidance on file access permissions for some htdig database files needed by rundig have been added to installation notes. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-19 10:59 Message: Logged In: YES user_id=75166 htdig-2.0.10-0.1.patch is a revised version of the patch that is compatible with MM 2.0.10 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-08 17:46 Message: Logged In: YES user_id=75166 htdig-2.0.9-0.1.patch is a revised version of the patch that is compatible with MM 2.0.9 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-03-06 16:22 Message: Logged In: YES user_id=75166 htdig-2.1cvs-20020306.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 12:30 GMT 6 Mar 2002 Known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-17 16:56 Message: Logged In: YES user_id=75166 htdig-2.1cvs-20011217.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 11:50 GMT 17 Dec 2001 The only known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-13 16:58 Message: Logged In: YES user_id=75166 htdig-2.1a3-0.1.patch is a revised version of the patch that is compatible with the code published in mailman-2.1a3.tgz on sourceforge. The only known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 17:33 Message: Logged In: YES user_id=75166 The htdig-2.0.8-0.1.patch version of the patch resolves a problem that can arise with htdig indexing if the web_page_url for a list uses other than the http addressing (some folks want to use https). While specified as for MM 2.0.8 the revised patch should work OK with 2.0.7, 2.0.6 and probably back as far as 2.0.3. If you do not have the requirement for using other than http addressing in you lists web_page_urls it probably isn't worth the trouble of upgrading to this patch level. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 11:08 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.8 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-27 12:00 Message: Logged In: YES user_id=75166 This patch should also apply without problems to Mm 2.0.7 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-09 11:54 Message: Logged In: YES user_id=75166 The htdig-2.0.6-03.patch version of the patch makes some previously hard-coded things configurable and enhances the capability to run the htdig searches and indexing on a different machine to the one delivering Mailman and Mailman's web UI. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444884&group_i…

1 0

[ mailman-Patches-444879 ] Archive indexer control to improve index
by noreply＠sourceforge.net 30 Jul '02

30 Jul '02

Patches item #444879, was opened at 2001-07-26 18:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444879&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Barrett (ppsys) Assigned to: Nobody/Anonymous (nobody) Summary: Archive indexer control to improve index Initial Comment: This patch is applicable to Mailman 2.0.6 release and supercedes ealier patches 401669 and 402422. This patch should improve the quality of search results returned by search engines such as htdig (http://www.htdig.org) where the seach engine's index builder responds to strings embedded in the html pages that are the subject of the indexing. The changes in this patch: 1. allow strings for enabling and disabling indexing to be defined in mm_cfg.py. 2. embeds those strings in the pages generated as the html version of a list's archive. By default nothing in the html changes. To get the desired effect, you must define ARCHIVE_INDEXING_ENABLE and ARCHIVE_INDEXING_DISABLE in mm_cfg.py You probably want to run this patch as follows: cd <mailman 2.0.6 untarred and unzipped directory> patch -p1 < <this patch file> See also the associated patch for integrating the htdig search software with mailman's internal archiver ouput. ---------------------------------------------------------------------- >Comment By: Richard Barrett (ppsys) Date: 2002-07-30 11:23 Message: Logged In: YES user_id=75166 indexing-2.0.13-0.1.patch is purely cosmetic to get no mumble application to MM 2.0.13 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-25 14:11 Message: Logged In: YES user_id=75166 indexing-2.0.11-0.1.patch should apply without problems to MM 2.0.12 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-05-23 09:50 Message: Logged In: YES user_id=75166 indexing-2.0.11-0.1.patch is a revised version of the patch that is compatible with MM 2.0.11 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-19 10:53 Message: Logged In: YES user_id=75166 indexing-2.0.9-0.1.patch should apply without problems to MM 2.0.10 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-08 17:43 Message: Logged In: YES user_id=75166 indexing-2.0.9-0.1.patch is a revised version of the patch that is compatible with MM 2.0.9 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-03-06 16:14 Message: Logged In: YES user_id=75166 indexing-2.1cvs-20020306.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 12:30 GMT 6 Mar 2002. Corrects problem noted or 5 Mar 2002 by nobody ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-03-05 21:41 Message: Logged In: NO When applying this patch I get an error with Hunk 1 and Defaults.py is not updated. This happens with the a clean download of the latest cvs installation (5 Mar 2002). Any ideas what the problem is? ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-17 16:53 Message: Logged In: YES user_id=75166 indexing-2.1cvs-20011217.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 11:50 GMT 17 Dec 2001 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-13 16:48 Message: Logged In: YES user_id=75166 indexing-2.1a3-0.1.patch is a revised version of the patch that is compatible with the code published in mailman-2.1a3.tgz on sourceforge. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 11:07 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.8 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-27 12:03 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.7 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444879&group_i…

1 0

Re: [Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use)
by J C Lawrence 30 Jul '02

30 Jul '02

On Mon, 29 Jul 2002 21:02:25 -0600 Jason R Mastaler <Jason> wrote: > barry(a)python.org (Barry A. Warsaw) writes: >> If what you say is the case -- builtin support isn't terribly useful >> without the shared whitelist -- then maybe it does make sense to >> defer until a later Mailman version. > Some users will not want to use a shared whitelist, but in my > experience, the vast majority will. I predict that if you add the > feature without this sub-feature, it will become a nagging FAQ. At its root its a privacy and entrance notification problem. Its not so much that the whitelist is private, but that entering it for discrete list populations is a hard edged and published (to the list owner or subscriber base) event, as distinct from the global whitelist. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

1 0

Re: [Mailman-Developers] Re: Cute TMDA use
by J C Lawrence 30 Jul '02

30 Jul '02

On Mon, 29 Jul 2002 20:55:27 -0600 Jason R Mastaler <Jason> wrote: > barry(a)python.org (Barry A. Warsaw) writes: >> So if we /don't/ build the functionality into MM2.1 (as Chuq is so >> sensibly arguing :) is there anything we need to do to implement the >> whitelisting TMDA fronted MM that is being proposed here? > I think we just need documentation. I've only ever combined MM and > TMDA under qmail, and it's quite easy. Given .qmail-list which posts > to the list, you just need to edit and add the following to the top of > the file: I have TMDA+Mailman (with MIME filters and other niceties) working under Exim. Doing the same under Postfix is a bit of a bitch due to effective UID/GID problems for executing pipe, but can be solved with the vtable trick detailed in the Postfix README. If you decide _NOT_ to roll TMDA-like features into v2.1 I'll continue with my project and should post documentation, scripts, and other relevant bits here in the next week or so. > Non-qmail MTAs aren't as flexible, so perhaps JC can comment on his > experiences? Mostly its as commented here and on the TMDA lists (macro limitations etc). There's a little problem with effective UID/GID for gaining access to the Mailman config.db, but that's a trivial problem under Exim if you follow the Exim HowTo as a base model. > In any case, I think the necessary changes (if any) would go into TMDA > and not MM. So, perhaps you are done. Yeah, plus a little plugin logic (eg web UI). -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

1 0

Cute TMDA use
by J C Lawrence 30 Jul '02

30 Jul '02

You can front a list with TMDA, pointing TMDA at your list's subscriber base and a local whitelist. TMDA then passes all subscriber mails straight thru to the list, but mail from non-subscribers is held until confirmed (at which point you can whitelist or not). The TMDA lists do this to decent effect. Nice side effects: No more problems with posters from non-subscribed addresses. They have a subscription to _GET_ mail and to define an allowed posting address. They can (trivially) define additional allowed posting addresses by just posting from them and confirming the post to get on the whitelist. You're now essentially back in the old days of the 1980s when we could safely run open lists. Almost all SPAM disappears. They don't confirm. Ditto viruses. Well some viruses might learn confirming down the road, but none do now and the confirmation steps can be trivially changed. -- J C Lawrence - ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

5 25

[ mailman-Bugs-588373 ] bug with 2.1b2 (something with cookies?)
by noreply＠sourceforge.net 30 Jul '02

30 Jul '02

Bugs item #588373, was opened at 2002-07-29 23:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=588373&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Marshall (paulmarshll) Assigned to: Nobody/Anonymous (nobody) Summary: bug with 2.1b2 (something with cookies?) Initial Comment: This is hopefully my third and final stupid question involving mailman. I have mailman 2.1b2 setup and mostly working (I can create lists, and post, etc...). However whenever I try to log into a list via the admin page to edit/delete/whatever to it, it comes up with this bug: Traceback (most recent call last): File "/var/mailman/scripts/driver", line 82, in run_main main() File "/var/mailman/Mailman/Cgi/admin.py", line 82, in main cgidata.getvalue('adminpw', '')): File "/var/mailman/Mailman/SecurityManager.py", line 208, in WebAuthenticate print self.MakeCookie(ac, user) File "/var/mailman/Mailman/SecurityManager.py", line 223, in MakeCookie c = Cookie.SimpleCookie() AttributeError: 'module' object has no attribute 'SimpleCookie' Is this a permissions problem? something to do with creating cookies...Honestly, I have no idea... I've searched some bug databases and most likely passed right over it, however I can't seem to find anything dealing with this error. Thanks for all the help. Paul ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=588373&group_i…

1 0

Re: [Mailman-Developers] Re: Integrating TMDA (was Re: Cute TMDA use)
by Dan Mick 30 Jul '02

30 Jul '02

> JRM> This is surely better than nothing, but the shared list is a > JRM> pretty integral feature IMO. I don't think I'd use the MM > JRM> built-in support until this was available in some form. > > I have to defer to you and others who have actually started using this > arrangement. If what you say is the case -- builtin support isn't > terribly useful without the shared whitelist -- then maybe it does > make sense to defer until a later Mailman version. If MM+TMDA does > the job, then that's probably good enough. Why does it matter? Doesn't that just cause the user to go through N confirmations per server instead of 1, but since the confirmations are nearly free, who cares?... Probably missing something again. But I'm on very few lists that share a server, so I'd expect the normal behavior of "one confirm per list per alien address" behavior anyway (I think the only multilist server I communicate with is python.org).

3 2