Mailman 3 May 1999 - Mailman-Developers

[ANNOUNCE] Mailman 1.0rc1
by bwarsaw＠python.org May 4, 1999

May 4, 1999

Hi folks, Mailman 1.0 release candidate 1 (1.0rc1) has just been uploaded to www.list.org. Barring any major screwups by me, this will be the final 1.0 release. The next step is to create the GNU web pages. I just want to personally thank everyone who's helped with ideas, contributions, suggestions, and support in getting us to where we are. Here are a few things to note about this release: - We have a logo contest winner! By a narrow margin, Dragon's logo has won. My thanks to the other 3 logo creators; in different ways I liked them all, and they are all much better than /I/ could ever have done! Mailman will now display Dragon's small logo on (most) generated pages; I may have missed a few, but those will all be fixed when we revamp the page designs after 1.0. You need to read the instructions in the INSTALL file for putting mailman.gif in a place that your Web server can find them, and for setting up the img src URL. Comments on how to improve this manual installation step would be appreciated. - There is a new cron/mailpasswd script which groups users by virtual domains if mm_cfg.VIRTUAL_HOST_OVERVIEW is true (the default). While I've tested this feature, I would /really/ appreciate some more detailed testing by you folks who run multiple virtual domains (hi Greg S. :-). Please, let's not wait until June 1 to find out something is broken, but also be careful not to spam too many of your users! - If anybody feels like they are being left out of the ACKNOWLEDGEMENTS file, or have any other updates for this file, please send them directly to me. I haven't kept up with this as well as I should have, so don't be shy. :-) That's all I can think of. Grab the tarball from http://www.list.org/mailman.tar.gz Enjoy, -Barry P.S. I'll probably somewhat unresponsive to the mailing lists for a while. I need to concentrate on getting the next JPython release out.

1 0

nomail issue ($.02 worth)
by Balazs Nagy May 4, 1999

May 4, 1999

Hiyas, I am sorry that I cannot do anything for Mailman right now because of my new job. BTW I read these lists and I get the CVS tree regulary. I think it would be nice if the users would be notified about their subscription status (parameters) with the monthly password notification. Just my two cents by now. -- Regards: Kevin (Balazs)

1 0

One sugestion to moderating
by Dan Ohnesorg May 4, 1999

May 4, 1999

I have chanded my ..admindb.. page, so that the submit button and radio buttons are inserted after the held message. It is match better, becouse you will first read the message and then make decision what now. I will sugest it as default for next releaeses. The patch is so simply, that I dont send it. It is better to make change manually. cheers dan ________________________________________ DDDDDD DD DD Dan Ohnesorg, supervisor on POWER DD OOOO Dan(a)feld.cvut.cz DD OODDOO Dep. of Power Engineering DDDDDD OO CTU FEL Prague, Bohemia OO OO work: +420 2 24352785;+420 2 24972109 OOOO home: +420 311 679679;+420 311 679311 ________________________________________ Pesimista vidi v ementalskem syru jen ty diry.

1 0

Re: [Mailman-Developers] Mailman on NT
by Harald Meland May 4, 1999

May 4, 1999

[Gianni Sandrucci] > - made some minor changes in Mailmal files configure and src/Makefile.in > > - after some fighting with permissions (I was forced to comment tests on > these matters in configuration script and C source code) succeded to > ./configure --with-cgi-ext=.exe > make install (no errors reported) [...] > - called: http://localhost/mailman/cgi-bin/admin.exe > > Got an error (reported below). It seems Python is not able to locate > Mailman modules in /home/mailman/Mailman. I suspect that the reason python isn't finding any modules, is because the C wrappers do some funky stuff with the environment variable PYTHONPATH before python is exec()ed. I have no NT experience whatsoever, so you'll need to get someone else to confirm whether messing with that environment variable is likely to affect Win-Python at all. If it is, have a look in src/common.c, and convince yourself that the magic involving PREFIX, SCRIPTDIR, MODULEDIR, PYTHON and run_script() works as it should. Good luck, -- Harald

1 0

Re: [Mailman-Developers] Envelope sender and list-admin address
by Harald Meland May 4, 1999

May 4, 1999

[Brian Ryner] > Hi- > > I reported a bug on this but I thought I'd also post here, becuause I > might try to correct this myself (and any advice would be appreciated). > > Basically, when a message is sent to the admin address (i.e. > mailman-developers-admin(a)python.org), the envelope sender is left > untouched when the message is resent. I don't think this is a good > idea. I agree -- we certainly don't want Mailman causing people to slacken their relaying restrictions. Unless anyone objects, I'll change Deliverer.DeliverToOwner so that it _always_ uses MailList.GetAdminEmail() as the envelope sender. -- Harald

1 0

Re: [Mailman-Developers] mailman and AFS?
by Harald Meland May 4, 1999

May 4, 1999

[Christopher Lindsey] > Now for the tricky part. AFS doesn't use standard UNIX permissions, > but instead depends on ACLs (ours uses Kerberos V for authentication). > To be able to write into the AFS space, any program or shell must > have a valid AFS token. > > I can do this by creating a "keytab" file; basically, that randomizes > the password but lets me use it in shell scripts, etc. I just need > to kinit against this file, do my operations, then do a kdestroy. > > Now for my questions: > > o where should I put these calls? I'm guessing that they should be > in wrapper, but do I also need to put it into every binary > in $prefix/cgi-bin? It appears that way... Both the wrapper and all the cgi-bin/* binaries use run_script() from src/common.c for exec()ing the python script that does the job. Off the top of my head, I can't think of anything that needs write access before run_script() is called. > o am I going to run into any locking issues with multiple email and > Web servers, or does mailman handle this? If Mailmans mailingliste locking scheme works on AFS, I don't think there should be any problems. > If so, how? See the MailList.Lock() and .Unlock() methods -- they currently use posixfile.lock(). > AFS (like NFS) often has problems with flock() or fcntl() > locking (so dot-locking is the preferred method). Changing Lock() and Unlock() should be pretty straightforward. > o does mailman actually do any permissions checking on files or > directories? These checks would fail in AFS Grepping the sources for ST_MODE told me of at least one place -- OutGoingQueue.isDeferred() works by checking the setuid bit of the queue file. If I remember my AFS correctly, there is no SUID bit -- so you'd need to change .enqueueMessage, .isDeferred and .deferMessage() to use some other scheme. > Any pointers and/or answers would be appreciated. Good luck, and let us know how things work out! -- Harald

1 0

Re: [Mailman-Developers] fork() problem and popen2.py test
by Harald Meland May 3, 1999

May 3, 1999

[Christian Tismer] > The reason turned out to be dependent wether Python 1.5 (the early > version, of course) was made with threads or not. > The threaded version had a bad effect on sys.stdin after an > os.fork(). sys.stdin was a "bad file number" in the child process. > Maybe these are known things, but there are some issues: [...] > To the Mailmen: > It was quite hard to track this error down through the > mailman scripts. Finally, I ended up if I made the deliver > fork temporarily into a do-nothing. > The "deliver" script does a number of forks. I does no proper > checking if the forks work (under Linux, btw., fork never returns > ENOMEM, so the check isn't safe yet). I don't understand -- "forker(tries)" in the "deliver" script tries fork()ing, catches any exceptions raised, and re-raises them if a) the error causing the exception weren't EAGAIN or b) this were failed fork() number "tries"+1. Catching the exception is about as far as you can go to "check if the forks work", IMHO -- when fork() stops working, there usually aren't very many clever things worth doing (short of giving up), are there? > Deliverer.py also trusts the os.popen very much. Well, os.popen() should bail out by raising os.error whenever it's behaving "untrustworthy", shouldn't it? > Anyway, sys.stdin is read without error checking in the deliver > script. I think, some more checks are necessary to guarantee that > failing deliveries get noticed. I don't think I have understood enough of the problem to fix this properly, so any suggestions on exactly _what_ those extra checks should check for would be nice :) -- Harald

1 0

Re: [Mailman-Developers] Stand-alone Mailman
by Harald Meland May 3, 1999

May 3, 1999

[Christopher Petrilli] > Gang, > > So I've been tossing this idea over in my head... what do you think of > using a derivitive of CGIHTTPServer.py to drive Mailman so that one > could have an "out of hte box" solution... Well, it wouldn't *really* be "out of the box" anyway, as it wouldn't have any built-in MTA. > now not everyone WANTS this, but in the Zope world, we've found that > for evaluation, the lower the entry-point requirement the better. Something like this would of course have to be optional -- but yes, I think it would be kinda cool. But, as you should be able to deduce from the lag on this response, you shouldn't be holding your breath :) -- Harald

1 0

Separating executables from data
by Dick Porter May 3, 1999

May 3, 1999

Attached is a patch against v1.0b11 which allows me to configure mailman with all executables installed on a read-only filesystem. The patch also has a few tests in configure.in nobbled, because I build on a different machine to the one that runs lists. (The mailman uid and gid tests seem to be superfluous anyway, as the only time the results are used in the code is in a Makefile rule that is never called). The FQDN and URL parameters have been hard-coded to a fixed string that I then edit with sed on the target machine when I install the RPM. I have left these changes in for completeness. I also include my RPM spec file. It has some vaguely interesting parts that are probably specific to my configuration (ie executables have to be in a directory owned by root and not writable by anyone else, due to Trusted Path Execution patches, and the mm_cfg.py has to be on a writable filesystem, hence the symlink into /etc) Even if these patches don't make it into the code, I'd appreciate it if someone could point out any potential problems with my configuration :-) - Dick PS I would have submitted these patches by jitterbug, but I couldn't see any way of attaching files there.

1 0

dots in list name -> archive not accessible?
by Gerhard Gonter May 2, 1999

May 2, 1999

Once upon a time, one group of users decided that they need a list called Assistent/Inn/En(a)wu-wien.ac.at and it took me a while to convince them, that the / would not work so they accepted Assistent.Inn.En(a)wu-wien.ac.at which worked quite well on Listproc... Today I moved the list, everything went fine except that the archives were not accessible from the list overview page. I tracked this problem down to Mailman/Cgi/private.py where this function is defined, which strips an extension from the directory name: | def getListName(path): | component = string.split(path, os.sep)[1] | root, ext = os.path.splitext(component) | return root If component is returned instead of root, everything seems to be working fine for this list and the other lists without dots in their name. Why should an extension be stripped? Is this a bug, a feature, or something that was left over from VMS times? P.S.: Yesterday I mailed an message about the problems our users have with automatically generated passwords. Neither my collegue nor I seem to have received the article, also, no flames appeared either ;) The article has been archived as http://www.python.org/pipermail/mailman-developers/1999-April/001040.html Did something go wrong with that? +gg -- Gerhard.Gonter(a)wu-wien.ac.at Fax: +43/1/31336/702 g.gonter(a)ieee.org Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria

2 1