Mailman 3 September 2000 - Mailman-Developers

I patched syncmail to look prettier to my eyes.
by zooko＠mad-scientist.com 29 Sep '00

29 Sep '00

Greetings, Mailman Cabalists! I followed the instructions[1] on SourceForge to get mail sent to my development list about CVS commits. Someone requested unified diffs instead of context diffs, and I agreed, so I made the following patch to syncmail, which passes the "-u" and "--minimal" flags to CVS diff, and which strips out unnecessary (to me) header lines from the cvs diff output. The project of which I speak, by the way, is Mojo Nation[2], an open source, highly distributed file sharing system with integrated micropayments, written in Python. Regards, Zooko (patch appended) [1] http://sfdocs.sourceforge.net/sfdocs/display_topic.php?topicid=52 [2] http://mojonation.net/ --- syncmail 2000/09/07 03:26:44 3.12 +++ syncmail 2000/09/20 20:09:35 3.19 @@ -3,6 +3,8 @@ """Complicated notification for CVS checkins. +Hello! Zooko touched this. + This script is used to provide email notifications of changes to the CVS repository. These email changes will include context diffs of the changes. Really big diffs will be trimmed. @@ -94,7 +96,8 @@ else: # This /has/ to happen in the background, otherwise we'll run into CVS # lock contention. What a crock. - diffcmd = '/usr/bin/cvs -f diff -kk -C 2 -r %s -r %s %s' % ( + # Zooko added "--minimal -u" here. --Zooko 2000-09-20 + diffcmd = 'cvs -f diff -kk --minimal -u -r %s -r %s %s' % ( oldrev, newrev, file) fp = os.popen(diffcmd) lines = fp.readlines() @@ -102,6 +105,11 @@ # ignore the error code, it always seems to be 1 :( ## if sts: ## return 'Error code %d occurred during diff\n' % (sts >> 8) + + # Zooko's hack to get rid of unnecessary header lines: + # (This hopefully includes only "diff" statements and unified diff text.) + lines = filter(lambda l: (not l) or (l[0] in "+-@d "), lines) + if len(lines) > DIFF_TRUNCATE_IF_LARGER: removedlines = len(lines) - DIFF_HEAD_LINES - DIFF_TAIL_LINES del lines[DIFF_HEAD_LINES:-DIFF_TAIL_LINES]

4 3

Reply-To bug in 2.0beta6
by Tokio Kikuchi 29 Sep '00

29 Sep '00

Hi, I think I traced a bug in 2.0beta6 in Mailman/Handlers/CookHeaders.py > # > # Reply-To: munging. Do not do this if the message is "fast tracked", > # meaning it is internally crafted and delivered to a specific user, > # or if there is already a reply-to set. If the user has set > # one we assume they have a good reason for it, and we don't > # second guess them. > if not fasttrack or msg.get('reply-to'): this line should be if not fasttrack and not msg.get('reply-to'): Sorry but I have no time to use diff. This bug caused confirm message to go list address in some cases (cf. -users discussion) Tokio

3 2

Security Contact for Mailman
by Alfred Huger 28 Sep '00

28 Sep '00

Hello, Can somene please direct me to the developer(s) in charge of security fixes for MailMan? Any help would be greatly appreciated. Alfred Huger VP of Engineering SecurityFocus.com

2 1

Re: [Mailman-Developers] mod_layout?
by J C Lawrence 28 Sep '00

28 Sep '00

On Wed, 27 Sep 2000 10:23:49 -0700 Chuq Von Rospach <chuqui(a)plaidworks.com> wrote: > has anyone tried to use mod_layout or one of the templating > systems with mailman (and/or any python cgis?) -- we had the > discussion a while back about graphic designs for virtual hosted > sites, and it came to me today that if one of these wrapper > packages works with python stuff, it might solve this problem > without hacking it into mailman... Much tho I like the idea, mod_layout presumes apache. As past traffic has shown, there are a reasonably significant number of people running Mailman under Boa, Zeus, etc rather than Apache. I'm not aware of a web server portable solution to templating for CGIs (haven't looked). -- J C Lawrence Home: claw(a)kanga.nu ---------(*) Other: coder(a)kanga.nu http://www.kanga.nu/~claw/ Keys etc: finger claw(a)kanga.nu --=| A man is as sane as he is dangerous to his environment |=--

2 1

mod_layout?
by Chuq Von Rospach 27 Sep '00

27 Sep '00

has anyone tried to use mod_layout or one of the templating systems with mailman (and/or any python cgis?) -- we had the discussion a while back about graphic designs for virtual hosted sites, and it came to me today that if one of these wrapper packages works with python stuff, it might solve this problem without hacking it into mailman... anyone know? if not, I'll put it on my list for things to try when I have a spare weekend... -- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com) And they sit at the bar and put bread in my jar and say 'Man, what are you doing here?'"

3 9

Mailman Enhancement Suggestion
by Stephanie Martinez 27 Sep '00

27 Sep '00

Just a suggestion that occurred to me, please note that I'm not subscribed to this list, so if you wish to reply to me you will have to do so at my address of stephanie(a)hawkbane.net. I LOVE Mailman, and its a wonderful program. It would be helpful for some people (I hope not just me) if there was a way to associate a name or nickname with an email address. Some people keep lists for administrative reasons, and it is easier to find the person we are looking for by name (rather than email address). While I'm at it, it appears that a person can unsubscribe from a list even if its set to confirm + approve. It would be nice if users could not unsubscribe themselves from these lists without approval also. Sometimes you need to ensure someone gets email from a list. Or maybe anothe roption added about needing confirmation to unsubscribe from administrator. Anyhow, thanks for a wonderful program. May Majordomo rest in peace :).

2 1

No problems today
by David Champion 27 Sep '00

27 Sep '00

I just want to say that for all the munging I've done on my 2.0 beta installation, I hadn't looked at the new admindb until just now. Wow, I like it a lot! Thanks! The rest of 2.0 looks good, too, but I'm impressed by how much improvement is superficially visible in admindb. It should go over well with the list admins. -- -D. dgc(a)uchicago.edu NSIT University of Chicago

1 0

internal mail archiver/htdig integration
by Richard Barrett 26 Sep '00

26 Sep '00

In commissioning Mailman I needed to provide a per mail list search facility which fully honored private list access constraints (i.e. if the use cannot read it then do not tell him it even exists in search results). In implementing this I have made some changes to the mailman-2.0beta5 source. What I have done is hardly rocket-science. That said it would be good for me if the work was integrated with the standard releases of Mailman so I do not have to keep applying my own unique patches to any subsequent releases. I don't know the protocol for doing this nor whether other developers think my work is worth incorporating into the mainline of Mailman's code. I've outlined the changes below and would appreciate some advice. btw: If there's a better way to achieve the same objectives then I'm more than happy to throw my changes away. I've integrated Mailman's internal archiver with htdig. Use of htdig is conditional on a new Mailman configuration variable being set, the use of the internal archiver and a list being subject to archiving. If these conditions are met then the relevant list-specific htdig conf files and such are created and maintained automatically. If you don't want the integration then turning of a single Mailman config variable makes this integration completely transparent. For qualifying lists the htsearch form is embedded in the list's archive index page, when that is generated by HyperArch.py, and hence is downstream of user authentication for accessing a private archive. Access to URL's returned by htsearch are all mediated by an additional wrapped cgi script called htdig.py which is similar to private.py. Similar in the sense that for private lists it requires the presence of a list authentication cookie or it rejects the access. For public lists it just responds with the html page requested. In the normal course of events the user's browser gets the authentication cookie on board while reaching the archive index page, to do a search, in the normal fashion. This approach means that changing a list from public to private or vice versa does not invalidate the htdig search files as access to archive html files in either type of list uses a common root in their URLs. An additional directory called htdig is created under each .../mailman/archives/private/<listname> in which the htdig search files and configuration file for each list are stored. An additional directory called .../mailman/archives/htdig holds symlinks to the list-specific htdig configuration files. .../mailman/archives/htdig is itself the target of a symlink in the directory in which htdig is configured to find its configuration files. [These symlinks are to allow htsearch to locate the list specific htdig conf files.] This directory arrangement meets that deleting a list in the normal fashion also disposes of related search stuff without any further effort or thought. The whole is rounded off with a cron initiated script which uses rundig to update list-specific search files on a regular basis iff each given list archive has had more data added to it since the script last ran. Changes have been made to the following mailman-2.0beta5 source files: Hyperarch.py 1. extra function to set up list-specific htdig creates list's htdig directory and generates list's htdig conf file in that directory. Logic added so that this function is called when archiving for the list is commenced. 2. added meta tags and and <!--htdig_noindex> tags in the html templates to improve quality of seach results and efficiency of htdig'ing 3. added htsearch form html template and logic to selectively include that when generating list index pages src/Makefile Added htdig to list of cgi scripts to get a wrapper for new htdig.py generated Defaults.py Added directives to provide control of htdig integration. Includes USE_HTDIG which enables/disables all the other changes if you want to use/not use htdig in this way. New files are: cgi script htdig.py mediates access to all htsearch results cron activated script nightly_htdig to selectively regenerate htdig search file Some tidy up of installer may yet be needed to finalise this work plus some minor installation documentation changes. ------------------------------------------------------------------ Richard Barrett, PostPoint 27, e-mail:r.barrett@ftel.co.uk Fujitsu Telecommunications Europe Ltd, tel: (44) 121 717 6337 Solihull Parkway, Birmingham Business Park, B37 7YU, England "Democracy is two wolves and a lamb voting on what to have for lunch. Liberty is a well armed lamb contesting the vote." Benjamin Franklin, 1759 ------------------------------------------------------------------

6 12

Fw: [Mailman-Developers] Re: [Mailman-Announce] Announcing Mailman 2.0 beta 6
by Ricardo Kustner 26 Sep '00

26 Sep '00

*sigh* what can we do about misbehaving vacation programs? I know it's hard to decide for such software who it should and shouldn't write a reply, but the least thing it could do is not reply to messages marked as 'Bulk' --- Forwarded Message --- From: Leann.Blackmon(a)state.co.us To: <mailman-developers(a)python.org> Sent: Sat, 23 Sep 2000 22:08:40 -0600 Subject: [Mailman-Developers] Re: [Mailman-Announce] Announcing Mailman 2.0 beta 6 I will be on vacation beginning 9/18/00 and returning on 9/25/00. http://www.python.org/mailman/listinfo/mailman-developers Ricardo. -- http://rixhq.nu "You think that's air you're breathing?" -- Morpheus

5 7

Announcing Mailman 2.0 beta 6
by bwarsaw＠beopen.com 26 Sep '00

26 Sep '00

Folks, I'm pleased to announce the release of Mailman 2.0 beta 6. In this release most of the bugs and patches submitted to SourceForge have been resolved. See below for a list of changes since 2.0 beta 5. I've tested this release with Python 1.5.2, 1.6, and 2.0beta1+CVS. This will be the last beta before 2.0 final. I think Mailman 2.0 is now stable enough to be unleashed on the unsuspecting public :). Besides, it's way overdue and there are lots of important new features that are backed up waiting for this to get out. I plan to release 2.0 final about a week after Python 2.0 final is released. That currently puts Mailman 2.0 final out on lucky Friday October 13th. If the Python release is pushed back, Mailman may be pushed back too. Much thanks to everyone who has helped Mailman to where it is, either through bug reports, patch submissions, important feedback, and extensive testing. I'd like to single out Jeremy Hylton on this release for coming to the rescue at the last minute and working on Pipermail to fix bugs, add support for non-ASCII charsets, and improve its performance. [Side note: I was in New York City last night doing a gig at the Lion's Den with my band, and I met the guitarist's Linuxhead network administrator friend. We were talking geek shop after the show and I mentioned I worked on "a mailing list manager". He said, "Oh, like Mailman?" :) ] As usual, you can get the tarball from SourceForge http://download.sourceforge.net/mailman/mailman-2.0beta6.tgz or list.org http://www.list.org/mailman.tar.gz or (soon) ftp.gnu.org ftp://ftp.gnu.org/gnu/mailman/mailman-2.0beta6.tgz Enjoy, -Barry 2.0 beta 6 (22-Sep-2000) - Building o Tested with Python 1.5.2, Python 1.6, and Python 2.0 beta 1. Conducted on RH Linux 6.1 only, but should work cross-platform. o Configure now accepts --with-username, --with-groupname, --with-var-prefix flags. See `configure --help' or the INSTALL file for details. o Setting the CFLAGS environment variable before invoking configure now works. o The icons are now copied into $prefix/icons at install time. Patch by David Champion. - Standards o Compliance with RFC 2369 (List-*: headers). Patch by Darrell Fuhriman. List-ID: header is kept for historical reasons. o Fixes by Jeremy Hylton to Pipermail in support of non-ASCII charsets, based on the Content-Type: and encoded-words in the original message. Mail headers are now decoded as per RFC 2047. o Many more bounce formats are detected: Microsoft's SMTPSVC, Compuserve, GroupWise, SMTP32, and the more generic SimpleMatch (which catches lots of similar but slightly different formats). - Defaults o Email addresses can now be obscured in Pipermail archives by setting mm_cfg.ARCHIVER_OBSCURES_EMAILADDRS to 1 (obscuring is turned off by default). Patch provided by Chris Snell. o The default NNTP host can now be set by editing mm_cfg.DEFAULT_NNTP_HOST. Patch by David Champion. o The default archiving mode (public/private) can now be set by editing mm_cfg.DEFAULT_ARCHIVE. Patch by Ted Cabeen. - Web UI o The variable details pages in the administrators interface is now `live', i.e. there's a submit button on the details page. o A link to the administrative interface is placed in the footer of the general user pages (authentication still required, of course!) o The user options change results page has a link back to the user's main page. o In the admindb page (for dealing with held postings), the default forward address is now listname-owner instead of listname-admin. This avoids bounce detection on the forwarded message. - Miscellaneous o Fixed config.db corruption problem when disk-full errors are encountered. o Command line scripts accept list names case-insensitively. o bin/remove_members takes a -a flag to remove all members of a list in one fell swoop. o List admin passwords must be non-empty. o Mailman generated passwords are slightly more mnemonic, and shouldn't have confusing character selections (i.e. `i' only, but no `1' or `l'). o Crossposting to two gated mailing lists should be fixed. o Many other bug fixes and minor web UI improvements.

3 3