Mailman 3 March 2000 - Mailman-Developers

Re: [Mailman-Developers] Mailman password and administrative reminders
by Dan Mick Aug. 14, 2003

Aug. 14, 2003

? This very message came to me with the following header: Errors-To: mailman-developers-admin(a)python.org All my bounces come to the list admin address, set in the admin webpage, in the second field of General Options. Do you have that set to something, and bounces still come to root? > 2. Bounces are sent to the poor postmaster instead of a -admin address. > I'm not entirely certain, but I think an Errors-To: header or something > like that in all Mailman messages might allow one to distribute that load > somewhat.

8 11

Membership management chunking requires two authentications..
by Ted Cabeen July 19, 2000

July 19, 2000

Mailman: 1.1 Python: 1.5.2 OS: Solaris 5.7 I don't know if this has been fixed in the CVS version, but I thought I'd submit it anyways. There seems to be a small authentication bug with the chunking in the membership management page. The page will load up correctly the first time it is accessed with the first chunk size shown. However, when you request a different chunk, it requires a reauthentication and then gives the chunk=0 page instead of the requested chunk. If you then click on the alternate chunk it loads fine. However, the additional click and authentication is annoying. -- Ted Cabeen http://www.pobox.com/~secabeen secabeen(a)pobox.com Check Website or finger for PGP Public Key secabeen(a)midway.uchicago.edu "I have taken all knowledge to be my province." -F. Bacon cococabeen(a)aol.com "Human kind cannot bear very much reality."-T.S.Eliot 73126.626(a)compuserve.com

3 4

Re-tries for failed SMTPDirect deliveries
by Barry A. Warsaw June 1, 2000

June 1, 2000

Last night, I added some code to queue messages that fail delivery when using SMTPDirect. What happens is this: If a message either totally fails delivery (e.g. the smtp socket connect fails) or partial delivery fails for some, but not all, recipients, then the message is stored on the file system for a re-try later. For every failed message, two files are created. The base name of these files is the SHA hexdigest dump of the message text. This should be nearly guaranteed unique. A new directory contains these files, called `qfiles'. The first file created is the complete plain text of the failed message. The second file is a marshal of useful information related to the failed delivery. This contains the listname and the failed recip list along with a few other moderately useful bits of info. There's a new cron script called `qrunner' which cruise the files in qfiles. It claims a lock (to prevent multiple qrunner processes) and then goes through each file it finds, attempting redelivery. If there are any problems reading a qfile file, it skips it for next time (assumes it's a transient problem with the file, but logs a message). When qrunner notices that the message has been handed off the the smtp daemon for all outstanding recipients, it deletes the two message files. I've moderately tested this stuff with total delivery failure by shutting off my smtp daemon, attempting some deliveries, turning it back on and running qrunner. I don't have the time right now to test partial delivery failures, but I still claim that without DSN support, these will be unlikely. Hopefully some of you can help look at this. I'm about to check all this stuff in. Let me know what you think. -Barry

3 9

pipermail/hypermail mbox-archive
by Thomas Wouters June 1, 2000

June 1, 2000

There was a short discussion a month or so ago about the hyperarch 'mbox' archives having the wrong kind of date in the 'From ' lines... 'unixfrom' lines should have a very specific dateformat, namely that which 'time.ctime' returns. The following patch fixes Archiver/HyperArch.py. However, I'm not entirely sure if it will work correctly in other locales... can anyone test that, and propose a locale-independant way of producing this format ? Grtz, -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

2 3

Re: [Mailman-Developers] race condition in locking ?
by Harald Meland May 2, 2000

May 2, 2000

[Thomas Wouters] > On Mon, Feb 07, 2000 at 09:31:44PM +0100, Ricardo Kustner wrote: > > > I wonder though what happens if some impatient moderator decides not to > > wait before the page finnishes loading, switches to a differen webpage and > > therefor breaks the python cgi process... will some approved posts stay in > > the queue instead? > > Try it out ! ;) It depends on the exact behaviour of both the > webbrowser and the webserver. Yup. This might produce a SIGPIPE, and/or the corresponding IOError EPIPE, and I've experienced that these didn't always get caught -- an attempt at a fix is near the end of run_main in <URL: http://www.uio.no/~hmeland/tmp/mailman-userdb/scripts/driver>, but I'm by no means positive that it's the Right fix. -- Harald

2 1

Bouncers/Exim.py
by Jim Tittsler April 10, 2000

April 10, 2000

Exim adds a header to bounce messages that might be used to catch the bounced addresses, rather than trying to parse the message text. I've been using this trivial bouncer for a while with my 1.2CVS installation and it seems to be doing the right thing. -- Jim Tittsler, Tokyo Python Starship http://starship.python.net/crew/jwt/

2 1

Re: [Mailman-Developers] race condition in locking ?
by Harald Meland April 7, 2000

April 7, 2000

[Thomas Wouters] > On Mon, Feb 07, 2000 at 10:01:36PM +0100, Harald Meland wrote: > > > My current CVS checkout is available ("live" :) under <URL: > > http://www.uio.no/~hmeland/tmp/mailman-userdb/>, with <URL: > > http://www.uio.no/~hmeland/tmp/mailman-userdb/Mailman/LockFile.py> > > being of special interest in this discussion... > > Ah, very cool. You'll find my current version of LockFile.py > attached, for reference, as you asked. Thanks, I've skimmed through most of it now. > I think the link() solutions, as opposed to the rename() solution, > is a better one, if you'll premit me. Sure :) > For one, you can check on lock ownership by statting your own > lockfile, which should only be touched by you, instead of reading a > possibly highly volatile lockfile. You can also doublecheck the > lockfile inode, see if it is equal to your own lockfiles' inode, to > confirm that you have the lock. ... the downside being that if, e.g., anyone tries to read the info in the lockfile in the middle of a refresh(), they'll get a ValueError -- which your module seems to take care of, but it all looks a bit convoluted to my eyes. I especially dislike that lock() has to call locked() _after_ the check on ST_NLINK, because further down in lock() there's code that might break a lock it really shouldn't (if it weren't for the nonatomic-write-of-lock-contents issue). I also see some bugs that are fixed in my module but still present in yours, but those are rather irrelevant to this discussion (as they can easily be ported to your module if that's the one we'll go for). Does anyone but Thomas and me have any opinions on which locking scheme is preferrable? I guess I don't have any very strong feelings about the issue ;), so any sagely advise on the matter would be welcome. [ I've tried to model my version of the module as closely as possible after the way Exim does its lockfile locking, the idea being that Exim really should have been around long enough to have solved these things correctly. Reading the longish comment from ca. line 1206 and onwards in src/transports/appendfile.c of the Exim distribution proved very helpful to me. Of course, when it comes to lock stealing and other ugly (but needed, I guess) stuff, Exim couldn't provide much help. ] > Ah, well, I couldn't find any parts of Mailman in the CVS tree that > acually _called_ steal, so I couldn't figure out what it should do > in borderline cases. The only place I know of is cron/gate_news. > However, reading your LockFile.py made me realise how to steal the > lock. LockFile.steal() now does its utmost best to steal the lock, > only failing if someone else is busy stealing the lock from us. It > returns 1 for success, 0 for failure, mostly because I wanted it to > signify that in some way. ... but the caller should note that steal() returning 1 does not necessarily imply that it is the owner of the lock (anymore). The steal() stuff is bound to be full of race conditions, AFAICT -- so whether it returns anything doesn't really matter (IMHO), as the return code truly can't be trusted anyway. Cheers, -- Harald

2 1

Re: [Mailman-Developers] cron/gate_news watermark == 0
by Harald Meland April 7, 2000

April 7, 2000

[Jim Tittsler] > A watermark value of 0 is used for two different purposes in cron/gate_news: > 1. the group has never been gatewayed, so "catch up" to the highest article > number > 2. the highest article number seen for the group is 0 (which can be a valid > "high article number" before the first posting in a newly created > newsgroup) > The result of this is the first article posted to the newly created newsgroup > fails to get gatewayed to the mailing list because the watermark for that > group is (still) 0 which is used as a flag to "catch up" so all that happens > is the watermark gets set to 1. > > I believe I have fixed that in my copy by using the value None for the first > time a group is gatewayed, allowing proper processing when the watermark is > truly article number 0. Hmmmm... When checking the contents of my "data/gate_watermarks" marshal, I find several old mailing lists with an entry stating that their watermark is 0 -- even though these lists aren't actually gating any newsgroups. As all these lists are rather old, I guess this could be how things were stored in some early Mailman version -- back when gate_news were forking processes to gate _all_ lists, regardless of whether the list in question had requested that any gating should be done, and the watermark file was written to by each and every child... On checking this with CVS, it appears that revision 1.7 of gate_news indeed has the behaviour I suspected, while 1.8, which was checked in 1998/12/18 00:22:23, seems to do it "right". The upshot of this is that any list touch by rev. 1.7 (and maybe earlier) which do not do any gating would possibly get *all* the messages present in the group it's gating from posted to it if it started gating after your patch was applied. A possible way to approach all this would be to have "make update" replace those 0 values in gate_watermarks with None values iff there are no other None values (i.e. only change things on the first time "make update" is run). Or, even better, move the per-list watermark info from gate_watermarks into the list's config.db, replacing any 0 values in gate_watermarks with None values in config.db. This has the advantage of reducing the number of different files that would have to be changed when cloning/renaming a list. -- Harald

3 2

check_perms bug?...
by Dan Mick April 5, 2000

April 5, 2000

Somehow, my /home/mailman/lists directory managed to get set with permissions check_perms didn't check for; it was set to d-wx-ws--x/mailman/mailman, which caused mailcmd to be unable to list the directory (no read perms). I fixed it once I figured it out, but I had a lot of check_perms runs in there before I finally figured it out...mostly because I was confused about what 'x' really means on a directory. But check_perms could have saved me time if it had checked for 'owner-and-group-read'; I think it should.

2 1

suggestion
by Ricardo Kustner March 31, 2000

March 31, 2000

Hi, How about moving things like the list welcome message, headers, footers and other multiple line texts out of the database and into seperate text files? And treat/edit them in the same way as the html templates... this would it also make it easier to edit them directly. I remember having a lot of difficulties (when I started using mailman about a year ago) with creating the welcome message because the textarea was too small and strange things happened when i cut/pasted it into the textarea with Netscape on Linux (I had to boot windows just to be able to enter the welcome message properly ;) ) Ricardo. --

3 3

Re: [Mailman-Developers] About MailMan site...
by Dan Mick March 31, 2000

March 31, 2000

Thomas Tschoepke Soares wrote: > I am trying to install mailman here but there are some problems... > > So, I have been trying to download the newer beta version but the domain > www.list.org even resolv at a ping command! This is surely a transient failure; www.list.org has been pretty reliable for me. But you're right; I can't get DNS for it either, and I can't ping its nameservers. The technical contact for the domain is aware and is working on the problem; they have a network outage.

1 0

About MailMan site...
by Thomas Tschoepke Soares March 31, 2000

March 31, 2000

Hi! I am trying to install mailman here but there are some problems... So, I have been trying to download the newer beta version but the domain www.list.org even resolv at a ping command! Could you provide an alternative place from where to get this prog? Or, even better, how about to include it in the sourceforge portal? Thank you, regards Thomas. | Thomas Tschoepke Soares | // Mate do | ttsoares(a)cedep.ifch.ufrgs.br |(~~~//~~) estrivo bendito! |--UIN:961141-------------------------------| \ / Amargo que |The fact is a secondary aspect of reality. | `_/' a gente bebe...

1 0

Re: [Mailman-Developers] A suggestion
by J C Lawrence March 30, 2000

March 30, 2000

On Thu, 30 Mar 2000 17:23:26 +0200 (CEST) Marek Obuchowicz <elephant(a)pld.org.pl> wrote: > I couldn't find the possibility of removing headers in mailman. > Removing 'Recieved' headers is ofen used by majordomo users (like > me in the past). I host one list and I'd like to hide senders' > Message-Id. Eeek! Bad! Bad! > How can I do it? Use a procmail filter inserted before the mailman script invocations. -- J C Lawrence Home: claw(a)kanga.nu ----------(*) Other: coder(a)kanga.nu --=| A man is as sane as he is dangerous to his environment |=--

1 0

A suggestion
by Marek Obuchowicz March 30, 2000

March 30, 2000

Hi! Sorry if i am writing to wrong address, but i couldn't find a better one :) I couldn't find the possibility of removing headers in mailman. Removing 'Recieved' headers is ofen used by majordomo users (like me in the past). I host one list and I'd like to hide senders' Message-Id. How can I do it? Greets, Marek -- __ Marek "Suonik" Obuchowicz, elephant(a)pld.org.pl /'_)___ Member of GNU generation, PLD project and "H" ( \ ____|\ http://www.projcom.com.pl/ http://www.pld.org.pl/ // || Home Page: http://suonik.art.pl/ (pgp-key is there)

2 1

admin approval and list archive
by Thomas Wouters March 27, 2000

March 27, 2000

There seems to be a bug in the pipermail archiving in combination with admin aproved messages. The bug is that, in the archive mbox, 'From ' lines will be missing from messages which have been passed through admin approval, which means that they will be considered part of the previous message or, if there is no previous message, that the mbox is invalid and no archive will be built. This happens because of one or two buglets, one in the mailbox standard module, and one possibly in the rfc822 module or otherwise in Mailman. When holding a message, the code uses 'str(msg)' (where msg is a rfc822.Message instance) to dump the pending message to a file. Unfortunately, rfc822.Message.__str__() only dumps the normal mail headers and the body, and *not* the 'From ' line, which is stored in rfc822.Message.unixfrom. I dont really think that is a bug in the rfc822 module, as the 'From ' line is not rfc822 but a sendmail (i think) addon for its own use, but it needs to be worked around in any case. The simple fix is attached. In the course of tracking this bug I also found out that the mailbox standard module drops the 'From ' line entirely, before it passes the message to the rfc822.Message constructor. At first I thought that this caused the problem, but now I'm not entirely sure, and I'm not in a position to test it at the moment. This is a bug though, but not in Mailman, and I already sent a fix for it to the python patches list. If anyone is willing to test this, and the above fix doesn't work on its own, grab the mailbox.py fix from the patches mailarchive. And, er, my apologies for this large a rant on this small a bug, it's late and I'm overworked, not spending enough time with python ;) PS: there'll probably be some offset in this patch, my cvs tree is still cluttered with unshared hacks ;) even if it fails, though, I'm confident most people will be able to apply it by hand ;) -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

2 2

Post to every list, just in case...
by Nigel Metheringham March 27, 2000

March 27, 2000

Having been away for a few days I've experienced a sense of things repeating on a short loop whilst reading my mail this morning. One particular thread was cross posted over 3 different mailman lists, although it appears to have been moderated out of one of them at least. So would it be possible for list people to have a little more discipline regarding the posting of messages across lists. Additionally do we need to consider:- 1. Hierarchical lists - ie moderated announce lists that post into other lists, with decent support for building a union of subscribers - maybe rather than subscribing x-users & x-developers to ax-nnounce, a way of telling the list to pull in these lists' subscribers too. 2. Filtering on lists to detect cross posting and do something... 3. An idea of what "something" should be :-) Nigel. -- [ - Opinions expressed are personal and may not be shared by VData - ] [ Nigel Metheringham Nigel.Metheringham(a)VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ]

1 0

French traduction of the templates
by Matthieu CAMUS (IUP MIME - 96000937) March 27, 2000

March 27, 2000

Hello, I'm a frenchy student in Computers Sciences and a true fan of Linux. For the needs of a project I used mailman. I have done the french traduction of the templates files in the /etc/mailman directory. I don't know how to do the traduction in the others files (eg *.py). There is a special function named get-text or something like that for the python's files ? Joined to this email the tar.gz of my traduction. Cordialy, Matthieu Camus e-mail: matthieu.camus(a)univ-lemans.fr

2 1

lock lifetime
by Ricardo Kustner March 24, 2000

March 24, 2000

One of the changes I have to make for my server is to increase the lock lifetime. I suspect that other people who don't have a speedy server either, might get the same problems as me... so maybe it should be mentioned in the install docs and/or moved to a global variable in mm_cfg.py... Below is an excerpt of a message from Thomas who fixed this for me.... For my server I've changed this to 300. "... In any case, you can easily try it out; in Mailman/MailList.py, on or around line 282, there should be a 'lifetime = 60', inside the constructor for the maillists' lockfile. Changing the '60' in, say, '600', should give you better mileage, at least until your machine gets so heavily loaded that a simple admin request takes ten full minutes to process ;) " Ricardo. --

4 4

subscription approval
by Ricardo Kustner March 24, 2000

March 24, 2000

Hi, Today I was subscribing to a list on securityportal.com, which is running LISTSERV... and then I noticed they have a nice way of approving your subscription: you can visit and URL which contains a unique hash that authorizes your request. actually I've been using the same technique for a chatroom signup procedure on our website and it's fairly easy to make... (since i was able to make it ;) ) the big plus of this is that if most of your list subscribers aren't too technical, it's much easier for them to subscribe... anybody can click on the link which their microsoft or AOL browser conviently convert to a hyperlink... (too often I see mails send to the admin with texts like "hi.. my auth code is 923482.. please subscribe me") this could also make unsubscribing very easy... just add a link at the bottom of the mail... and once visited the user gets the choice to unsubscribe (with or without supplying a password?) anyway, i know this wont make it to 2.0, but I hope this could be a nice feature for the next version... Ricardo. --

1 0

[ANNOUNCE] Mailman 2.0 beta 1
by Barry A. Warsaw March 24, 2000

March 24, 2000

I've just uploaded the Mailman 2.0 beta 1 tarball to www.list.org. I decided to name the new version "2.0" because of the architectural changes that have been made. See the excerpt from the NEWS file below for details of what's changed since version 1.1. Two important things to take note of. You will need Python 1.5.2 to run this version of Mailman. Also, if you are upgrading from Mailman 1.x you will need to read the UPGRADING file for instructions. I don't plan to make wider release announcements until 2.0 final is ready to go, but I also don't expect the beta cycle to be very long. We'll see! Enjoy, -Barry -------------------- snip snip -------------------- - A new bundled auto-responder has been added. You can now configure an autoresponse text for each list's primary addresses: listname(a)yourhost.com -- the general posting address listname-request@... -- the automated "request bot" address listname-admin@... -- the human administrator address - The standard UI now includes three logos at the bottom of the page: Dragon's Mailman logo, the Python Powered logo, and the GNU logo. All point to their respective home pages. - It is now possible to set the Reply-To: field on lists to an arbitrary address. NOTE: Reply-To: munging is generally considered harmful! However for some read-only lists, it is useful to direct replies to a parallel discussion list. - There is a new message delivery architecture which uses a pipeline processor for incoming and internally generated messages. Mailman no longer contains a bundled bulk-mailer; instead message delivery is handled completely by the MTA. Most MTAs give a high enough priority to connections from the localhost that mail will not be lost because of system load, but this is not guaranteed (or handled) by Mailman currently. Be careful also if your smtpd is on a different host than the Mailman host. In practice, mail lossage has not be observed. For this reason cron/run_queue is no longer needed (see the UPGRADING file for details). Also, you can choose whether you want direct smtp delivery, or delivery via the command line to a sendmail-compatible daemon. You can also easily add your own delivery module. See Mailman/Defaults.py for details. - A similar pipeline architecture for the parsing of bounce messages has been added. Most common bounce formats are now handled, including Qmail, Postfix, and DSN. It is now much easier to add new bounce detectors. - The approval pending architecture has also been revamped. Subscription requests and message posts waiting for admin approval are no longer kept in the config.db file, but in a separate requests.db file instead. - Finally made consistent the use of Sender:/From:/From_ in the matching of headers for such things as member-post-only. Now, if USE_ENVELOPE_SENDER is true, Sender: will always be chosen over From:, however the default has been changed to USE_ENVELOPE_SENDER false so that From: is always chosen over Sender:. In both cases, if no header is found, From_ (i.e. the envelope sender is used). Note that the variable is now misnamed! Most people want From: matching anyway and any are easily spoofable. - New scripts bin/move_list, bin/config_list - cron/upvolumes_yearly, cron/upvolumes_monthly, cron/archive, cron/run_queue all removed. Edit your crontab if you used these scripts. Other scripts removed: contact_transport, deliver, dumb_deliver. - Several web UI improvements, especially in the admin page. - Remove X-pmrqc: headers to prevent return reciepts for Pegasus mail users. - Security patch when using external archivers. - Honor "X-Archive: No" header by not putting this message in the archive. - Changes to the log file format. - The usual bug fixes.

5 6

Re: [Mailman-Developers] Betas coming soon
by Dan Mick March 24, 2000

March 24, 2000

> [1] To closest way I can think of[2]: put it on screen, . . . > [2] And I shudder to think ;-) Hey, nesting footnotes is illegal. Somebody arrest that guy. ;)

1 0

Sender: header in 2.0beta1
by Gergely Madarasz March 23, 2000

March 23, 2000

Hello, Previous versions always put Sender: <listname>-admin@<domain> in all mails sent out to the list... it seems that with the new sendmail delivery module it has some issues... with exim the mailman user has to be listed in the trusted_users option for this to work, if it is not listed, the Sender: header becomes mailman@<domain> -- Madarasz Gergely gorgo(a)caesar.elte.hu gorgo(a)linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/

5 11

Re: [Mailman-Developers] Sender: header in 2.0beta1
by Nigel Metheringham March 23, 2000

March 23, 2000

gorgo(a)caesar.elte.hu said: > I've got it working... now smtplib can be told to use '/path/to/ > sendmail -bs' instead of connecting to localhost:25, and talk smtp > there (no addresses in the shell, perhaps a bit better error > handling). There is still a problem though... the Sender header gets > rewritten this way too... but now it becomes nobody@<domain>, I > haven't got the faintest clue why this happens, no process should run > as nobody here... The MTA should still know the UID its invoked under - exim will have the same Sender: problems as a straight CLI, and so the invoking user will still need to be trusted (or your MTA's equivalent). Also any loading issues from command line invocation still apply to an "mta -bs" invocation - although its probable that I am simply overly paranoid about this. Nigel. -- [ - Opinions expressed are personal and may not be shared by VData - ] [ Nigel Metheringham Nigel.Metheringham(a)VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ]

2 1

Betas coming soon
by Barry A. Warsaw March 23, 2000

March 23, 2000

Folks, Okay, I think I solved the last major hurdle before I can start releasing the new betas. Mailman should now lazily update it's old pending requests "database" to the new style external requests.db file. Wasn't as hard as I thought it would be. You will still have to be careful when upgrading from 1.1/1.0 to the new version. Please read/debug my recommendations in the UPGRADING file for details (after I check it in). While I'm pretty sure upgrading will work, I really need feedback from you beta testers. For now, I'd say you should be careful upgrading any operational site, but on the other hand I want to encourage you to test this stuff as much as possible. All feedback is welcome. Now, my questions. 1) Notice I haven't said "upgrade to 1.2" because I'm going to call the new release 2.0. While there aren't that many outwardly visible differences, there are enough architectural and schema changes, that I believe a 2.0 label is warranted. Plus, I want to give a stronger indication that the changes may be, er, significant. This means that if I really screw up 2.0, I can get a few 2.x bug patches out in quick succession. This also means that the i18n'd Mailman will likely be called 3.0. What's in a number anyway? :) 1) I've thought about being really parental about the upgrade, by essentially forcing people to read the UPGRADING file before "make" will succeed. I think I have a trick that will work, but I'm not sure it's a good idea. On the one hand it /might/ (only might) save lazy or novice upgraders some headaches by forcing them to read the manual first. One the other hand, it'll be really annoying either to those who are doing a fresh install, or who are upgrading but know what they're doing. So, do you think it would be a good idea to force everyone to read UPGRADING before "make" succeeds? Watch for the final round of checkins some time (hopefully) this week. After that I'll spin the 2.0beta1 tarball. I'm pretty sure the current CVS snapshot is very close, modulo updating the docs. I still need to get through the email backlog (sigh) and the Jitterbug database, but I can do that while the betas are out on the street. Cheers, -Barry

4 3

PairList error (fwd)
by sigma＠pair.com March 22, 2000

March 22, 2000

In the last week or so, we've been seeing the following error and traceback on several pages, including our main listinfo page at http://www.pairlist.net/mailman/listinfo/ I've searched and found nothing about this error. Can someone point me in the right direction, hopefully? Thanks, Kevin Martin sigma(a)pair.com ----- Forwarded message ----- Bug in Mailman version 1.2 (experimental) We're sorry, we hit a bug! If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! Traceback: Traceback (innermost last): File "/usr/mailman/scripts/driver", line 112, in run_main main() File "/usr/mailman/Mailman/Cgi/admin.py", line 67, in main mlist = MailList.MailList(listname) File "/usr/mailman/Mailman/MailList.py", line 69, in __init__ self.Load() File "/usr/mailman/Mailman/MailList.py", line 839, in Load raise Errors.MMBadListError, ('Failed to unmarshal config info: ' TypeError: __add__ nor __radd__ defined for these operands Environment variables: Variable Value DOCUMENT_ROOT /usr/www SERVER_ADDR 216.92.1.92 HTTP_ACCEPT_ENCODING gzip SERVER_PORT 80 PATH_TRANSLATED /usr/www/isc-agent-newsletter GATEWAY_INTERFACE CGI/1.1 HTTP_ACCEPT_LANGUAGE en,zh-CN SERVER_NAME www.pairlist.net HTTP_CONNECTION Keep-Alive HTTP_USER_AGENT Mozilla/4.7 [en] (WinNT; U) HTTP_ACCEPT_CHARSET iso-8859-1,*,utf-8 HTTP_ACCEPT image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* REQUEST_URI /mailman/admin/isc-agent-newsletter PATH /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin QUERY_STRING SCRIPT_FILENAME /usr/mailman/cgi-bin/admin PATH_INFO /isc-agent-newsletter HTTP_HOST www.pairlist.net REQUEST_METHOD GET SERVER_SIGNATURE SCRIPT_NAME /mailman/admin SERVER_ADMIN webmaster(a)pairlist.net SERVER_SOFTWARE Apache/1.3.9 (Unix) PYTHONPATH /usr/mailman SERVER_PROTOCOL HTTP/1.0 REMOTE_PORT 1047

1 0