Mailman 3 November 2000 - Mailman-Developers

Re: [Mailman-Developers] Postfix, Mailman, no aliases file, neat setup?
by J C Lawrence 16 Nov '00

16 Nov '00

On 16 Nov 2000 16:09:38 -0500 Owen Taylor <otaylor(a)redhat.com> wrote: > Well, you can't lose the aliases file, but you can make it pretty > darn invisible. Yeah, I'd gotten that far. I'd really like to get entirely rid of the Mailman alias file however. -- J C Lawrence claw(a)kanga.nu ---------(*) : http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=--

1 0

Running Mailman CGI under Zope ZServer
by Fred Wilson Horch 16 Nov '00

16 Nov '00

Hello out there, I'm looking for someone with some more Zope "Zen" to help me figure out how to add support for legacy CGI scripts (specifically Mailman 1.1) to Zope. To recap, I know and understand how to get Apache to play nicely with Zope. What I'm trying to do is remove the need for Apache by allowing ZServer to serve CGI scripts itself. The motivation is to allow me to run Mailman 1.1 on my Zope site without having to have Apache (or any other web server) configured and running. First, am I really the first person to try running CGI scripts from ZServer? I have found some hints here and there of people doing somewhat similar things, but I haven't yet found a product for easily adding legacy CGI scripts to a Zope site. It seems most people run Zope behind Apache. Is ZServer really slow or buggy or something? Second, is Mailman going to be integrated with Zope? It seems like a natural fit. It would be nice to move away from the pipermail archiving and use the Zope object database for archiving messages instead. Third, thanks to code from Eric Walstad and Chris Withers (author of PathHandler), I have hacked up an external method that sort of works. It attempts to add to Zope the functionality of ScriptAlias in Apache. But I'm running into some problems with the HTTP header. The attached code simply ignores the HTTP header sent by the Mailman CGI script, letting Zope do its thing. But this becomes a problem when Mailman wants to set cookies for authentication. Can anyone help me figure out how to convince Zope to let the CGI script send both the HTTP header and message body? Thanks, Fred Here's my external method. It is called by a Path Handler object. Some notes: 1) REQUEST['PATH_INFO'] seems to be brain dead 2) the path_to_handle key is inserted by the PathHandler product 3) this is written for Linux; I'm not sure how Windows handles os.popen 4) I don't understand why sometimes this function gets called with one argument and sometimes with two -- I always just ignore the second argument import os, os.path, string def testing(self, second=None): if self.REQUEST.has_key('path_to_handle'): script = self.REQUEST['path_to_handle'][0] if script: script_path = '/home/mailman/cgi-bin/%s' % script if os.path.isfile(script_path): ENV = '' if len(self.REQUEST['path_to_handle']) > 1: ENV = ENV + 'PATH_INFO=/%s' % string.join(self.REQUEST['path_to_handle'][1:],'/') elif self.REQUEST['PATH_INFO'][-1] == '/': ENV = ENV + 'PATH_INFO=/' ENV = ENV + ' HTTP_HOST=%s' % self.REQUEST['HTTP_HOST'] ENV = ENV + ' SERVER_NAME=%s' % self.REQUEST['SERVER_NAME'] f = os.popen("/usr/bin/env %s %s" % \ (ENV, script_path)) header = 1 while header: if (f.readline() == '\n'): header = 0 output = f.read() # grab the output of the CGI here status = f.close() else: return '%s: CGI script not found.' % script else: return 'No CGI script specified.' else: return 'No path to handle.' return output + '<hr>' + str(self.REQUEST.keys()) + '<hr>' + str(self.REQUEST)

1 0

Postfix, Mailman, no aliases file, neat setup?
by J C Lawrence 16 Nov '00

16 Nov '00

I'm looking to setup a test Mailman site under Postfix (need to do some performance modelling of Exim against Postfix under Mailman for a given membership list). I can get a basic setup working no problem -- now I'm looking to duplicate the neater aspects I already have under Exim, such as losing the Mailman aliases file, etc. Anybody already done this? -- 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 |=--

3 4

Re: [Mailman-Developers] Postfix, Mailman, no aliases file, neat setup?
by Owen Taylor 16 Nov '00

16 Nov '00

barry(a)digicool.com (Barry A. Warsaw) writes: > >>>>> "OT" == Owen Taylor <otaylor(a)redhat.com> writes: > > OT> Well, you can't lose the aliases file, but you can make it > OT> pretty darn invisible. > > >> From postfix's main.cf: > > OT> alias_maps = hash:/etc/aliases,hash:/home/mailman/aliases > > I do this. > > OT> And the following patch automatically updates the file. > > A couple of notes. First, the version of newlist that's going to be > in rc3 (some time today) has a -o/--output switch that does the > appending to a specified file, somewhat like the way your patch does > (although the file name is taken from the command line and a few > other minor differences). Hmmm, it seems to me that that should be in the config system somehow - so everybody running newalias doesn't need to know to use the flag. (I can set up a wrapper script, but that isn't so nice.) > But the real problem is a permissions problem. Say you run postalias > as yourself, because you installed Mailman. Or say you installed it > as user `mailman', and that's the user you run postalias as. Then the > resulting aliases.db file will be owned by you (or `mailman') and > Postfix will try to deliver email destined for those addresses as your > (or mailman's) gid, but not as the gid you compiled into the wrapper > script. > > Thus I found that I had to run newaliases (a.k.a. postalias) as root > for the gids to be correct. Well, I have the mailman gid as the gid compiled into the wrapper script, so all mailman processesing occurs with the mailman uid/gid. I guess this doesn't work in general, though it works well for our setup. > Not an insurmountable problem, but it's a pain. It would be nice if > Postfix could be configured to automatically run newaliases if > necessary (maybe there already is such an option?). Well, it wouldn't very secure if a user could put something into an alias file, and then postfix would compile that into an alias.db that is executed with root permissions... Basically, from a security point of view, the person composing the alias file can put arbitrary commands into the alias file, so the execution of commands in the alias file has to be done with the permissions of the owner of the file. Regards, Owen

1 0

Announcing Mailman 2.0 release candidate 3
by barry＠digicool.com 16 Nov '00

16 Nov '00

Mailman 2.0 release candidate 3 is now available from SourceForge at http://sourceforge.net/project/showfiles.php?group_id=103 www.list.org should be updated soon (I'm not going to bother the gnu.org guys again until 2.0 final is released). Excerpts from the NEWS file are given below. This should quash the few known 2.0rc2 buglets. Of course the on-line documentation is available at: http://mailman.sourceforge.net New goal for 2.0 final: Wed 22-Nov-2000 Enjoy, -Barry -------------------- snip snip -------------------- 2.0 release candidate 3 (16-Nov-2000) - By popular demand, Reply-To: munging policy is now to always override any Reply-To: header in the original message, if reply_goes_to_list is set to "This list" or "Explicit Address" - bin/newlist given -q/--quiet flag instead of the <immediate> positional argument - Hopefully last fix to DEFAULT_URL not ending in a slash sensitivity - 2.0rc2 buglets fixed: o newlist argument parsing o updating with unlocked lists o HyperArch.py traceback when there's no Content-Transfer-Encoding: header - SourceForge bugs fixed: 122358 (qmail-to-mailman.py listname case folding) - SourceForge patches applied: 102373 (qmail-to-mailman.py listname case folding)

1 0

Future of pipermail?
by Gunnar Evermann 16 Nov '00

16 Nov '00

What are the current plans about the html archiver in mailman? The major shortcomings of pipermail I see are: - doesn't decode MIME - doesn't handle mixed charsets - no search engine - somewhat convoluted code. I run a mailing list with a lot of subscribers from Asia who use MS Outlook, invariably posting (English) messages spuriously tagged as CJK charsets (but only using the ASCII subset) and gratuitously encoded in base64. Therefore I am motivated to find a solution to handling MIME. :-( I have hacked base64 support into pipermail and am currently looking at supporting MIME (probably using mimecntl.py), but this will just be short-term fixes. I know I could just switch to MHonarc or whatever but I like the idea of having a nicely structured, modular archiver tightly integrated with mailman. Are there people working on on pipermail or a replacement of it? Gunnar

2 1

Reverting question
by Phil Barnett 16 Nov '00

16 Nov '00

Am I likely to encounter problems going from 2.0rc2 to 2.0b6? Did any data formats change? -- Phil Barnett mailto:midnight@the-oasis.net WWW http://www.the-oasis.net/ FTP Site ftp://ftp.the-oasis.net

10 21

mailman 2.0 beta 5 problem
by Nils Lohner 16 Nov '00

16 Nov '00

I've got a problem with mailman. I installed the debian package ii mailman 2.0beta5-1 Powerful, web based list processor and after setting up a list tried the menus. I've got several problems and questions. - in the apache error log: client denied by server configuration: /usr/doc/mailman/images/mailman.jpg I've tried allowing everything to man /usr/doc/ work as in the Readme.debian (in the .deb) but no luck. - when I submit my changes to something it tries to contact www.localhost.com This seems to be exclusively a cgi problem. - when at http://131.101.98.199/mailman/admin the link for "General list information can be found at the mailing list overview page." points up one level (i.e. http://131.101.98.199/listinfo) I'll dig into this more tomorrow... help appreciated. Thanks, Nils.

1 0

Re: [Mailman-Users] Re: [Mailman-Developers] Reverting question
by Marc MERLIN 15 Nov '00

15 Nov '00

[Reply-To set to mailman-users(a)python.org] On Tue, Nov 14, 2000 at 06:13:53PM -0800, Chuq Von Rospach wrote: > At 5:50 PM -0800 11/14/00, Marc MERLIN wrote: > >2) If you don't want to take that advise, you certainly shouldn't overwrite > > a users' reply to with the list's > > I'll disagree. If you feel you must coerce reply-to, coerce it > unconditionally. You've already decided the list's needs outweigh the A few others mentionned that. The problem here, is that by putting a reply-to, you are already trying to prevent me from replying directly to the poster (well, not quite since mutt lets me tell it to ignore all those reply-tos), but by munging reply tos unconditionally, you are completely preventing me from replying to someone who has a non valid from address and set a good reply-to, or someone who'd like me to reply to him at another address. Doing a reply-to rewrite also prevents me from Ccing a second list and setting a reply-to there to move the discussion. That said, I could see why others would prefer unconditionally overwriting the reply-to. Well, in both cases, you lose, which is yet another reason why lists should not set a reply-to :-) I think I agree with JC in saying that short of removing the reply to misfeature altogether, unconditional rewriting should probably be an option On Wed, Nov 15, 2000 at 12:27:14PM +0800, Gregory Leblanc wrote: > Fine, that's all well and good, munging reply to is harmful. Sometimes > the harm that it causes is less than the harm that it prevents. I've yet to have a single person show me what harm not munging reply-to creates... It's all about users that have been trained to do the wrong thing and some of them who then believe it's the only way to go. > This is a good policy in most cases, but there ARE some where it doesn't > make sense. Yep, the only one I know is onelist which tries to force as many traffic back to the list in order to spam you with more messages which each contain a small add they make money on. Ok, more seriously, the only downside of group replies is that for MUAs that don't support list-reply, like mutt does, the sender gets two copies of the answer (which are easy to get rid off by removing duplicate messages that contain the same message id) > I'm sorry, but this is silly. If you're going to write reply-to headers > via your MLM, you need to write them ALL the time, otherwise you end up > with strange and un-predictable behaviour. Keep the reply-to header Point taken. The other option is wrong too though, for the reason I explained. But I guess if you choose to shoot yourself in the foot, it'd be nice to be able to chose which gun you're going to use (i.e. make the unconditional rewriting an option) > certainly, but if headers are sending mail back to the list, the user's > reply-to really doesn't make much difference, unless you need to send a > private reply. If you're sending a private reply, you can get it out of > the x-reply-to header. Great, I need to patch my MUA some more to attempt to deal with all this misconfiguration nonsense. On Tue, Nov 14, 2000 at 11:42:53PM -0500, Tanner Lovelace wrote: > Marc MERLIN wrote: > > > > The irony of this coming back over and over again... > > http://www.unicom.com/pw/reply-to-harmful.html > > One good URL deserves another (straight from the > "reply_goes_to_list Option" documentation): > > http://www.metasystema.org/essays/reply-to-useful.mhtml Yeah, except that the author is full of shit. Ok, I'll bite. - "Reply-To gives the respondant an option which would not otherwise exist: namely the ability to reply only to the list." false, see list-reply function in good MUAs (mutt is one) - "If you use a reasonable mailer, Reply-To munging does provide new functionality, namely the ability to reply only to the list" No comment... (the author completely ignores list-reply, and says that MUAs should all be patched to allow overriding reply-tos so that they can continue to be misused) - "Reply-To munging adds additional functionality, it actually increases freedom of choice" *cough* bullshit *cough* For one, it prevents a thread across two lists and the redirection to one list or a third list. - some mailers apparently do not have a separate reply to all function Ok, 1) I have yet to see one 2) in the point above, the author was saying that any MUA that can't override a reply-to is not a reasonable mailer and shouldn't be used. The irony... - "For discussion type lists, I would estimate that ninety percent of the time, people want to reply to the list" Yeah, so? That's why you have several reply functions, where one does not require more work than the other (the author mentions having to type addresses by hand, I'm not sure why) - "Some administrators claim that munging Reply-To headers is harmful because it surprises people, and can cause damage when things go awry" Damn straight. If you reply to the list by mistake due to reply-to munging, you look like an idiot, or worse. If you reply to the sender only by mistake, no harm is done, the mistake can be fixed. - "It's What People Want" Yeah, there are misguided people out there, and they are often vocal. Users typically know nothing about mail standards or what header sender vs envelope sender means. I don't think there opinion is that relevant :-) Ok, more seriously, users do matter but if they're trained the wrong way when they start, some get very resistant to change, regardless of whether it's a good thing or not. We did get a bit off topic here, I apologize to all the people who already know about all this, but since we have lots of listmasters here, I'm hoping a few with switch, and hopefully more will configure their lists the right way in the first place (that's when it's easy, changing is hard) > There are arguments on both sides for this issue. I personally think it > depends a lot on what the people on your list prefer. I run a large > non-technical mailing list where we tried making the "Reply-To" point to > the list for a while. Unfortunately, it resulted in someone accidentally > posting a very unflattering message about someone else on the list. Yep, this happens all the time. Many of us have seen this. > the "Reply-To" not point to the list. For other lists, however, I think > it could be advantageous. Because of that, I think that letting the list > administrator decide, rather than the software, is the best method. While I'm very much against reply-to munging (duh!), I'm for freedom of choice. I do think that mailman should offer a reply-to option, but with a very big disclaimer and maybe this discussion (or another one) so that inexperienced listmasters realize what they're doing. > I also think, though, that sometimes setting the "Reply-To" and sometimes > not, depending on whether or not it has already been set has the > potential to confuse a lot of people. If you're going to provide *that* > functionality, you should make sure it is *extremely* well documented. Agreed. Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f(a)merlins.org for PGP key

2 1

Info on newlist bug
by Phil Barnett 15 Nov '00

15 Nov '00

Here is the traceback for the failure. Now that I think about it, it's probably that the bin/newlist executable is looking at the 0 parameter instead of the 1 parameter. For example, on the command line bin/newlist test bin/newlist is parameter 0 test is parameter 1 Notice that the expected directory should have been: '/home/mailman/archives/private/test.mbox' but was instead: '/home/mailman/archives/private/bin/newlist.mbox' I've been looking in the code to see where this might be going wrong, but haven't gotten anywhere. -----------traceback------------- [root@taz2 mailman]# bin/newlist test Enter the email of the person running the list: midnight@the- oasis.net Initial bin/newlist password: Traceback (innermost last): File "bin/newlist", line 213, in ? main(sys.argv) File "bin/newlist", line 163, in main mlist.Create(listname, owner_mail, pw) File "/home/mailman/Mailman/MailList.py", line 775, in Create self.InitVars(name, admin, crypted_password) File "/home/mailman/Mailman/MailList.py", line 335, in InitVars Archiver.InitVars(self) # has configurable stuff File "/home/mailman/Mailman/Archiver/Archiver.py", line 108, in InitVars Utils.mkdir(self.private_archive_file_dir) File "/home/mailman/Mailman/Utils.py", line 568, in mkdir os.mkdir(dir, mode) OSError: [Errno 2] No such file or directory: '/home/mailman/archives/private/bin/newlist.mbox' -- Phil Barnett mailto:midnight@the-oasis.net WWW http://www.the-oasis.net/ FTP Site ftp://ftp.the-oasis.net

3 4