Mailman 3 August 2001 - Mailman-Developers

Re: [Mailman-Developers] sendmail
by Harold Paulson 30 Aug '01

30 Aug '01

Hi, Won't this start Sendmail up listing ONLY on the alternate port? Since most of us run Mailman as an *extra* feature on our mail servers, this probably isn't what people will want. Is there a simple CLI way to start up Sendmail listening in the usual skeptical way on 25, AND in just-do-what-you-are-told mode on a local port? - H On Sun, 12 Aug 2001 23:26:54, "Chuq Von Rospach" wrote: I did this a little differently, since I know that tweaking sendmail.cf files gives many people hives, and so people aren't likely to do it. It's also unneccesary. You can do this without modifying your sendmail files at all. Instead, in your startup script, add: /usr/sbin/sendmail -bd -ODeliveryMode=defer \ -ODaemonPortOptions=Name=MSA,Port=NNNN,M=E,Addr=127.0.0.1 Where NNNN is some port number not otherwise used (you can test if something's in use by doing "telnet localhost NNNN" -- if it's refused, there's no daemon listening) This sets up a sendmail process listening to the alternate port, in DEFER mode, but set to talk only to the localhost interface, so it's not accessible by anyoneother than your local machine: no open relay problems. -- Harold Paulson Sierra Web Design haroldp(a)sierraweb.com http://www.sierraweb.com VOICE: 775.833.9500 FAX: 810.314.1517

2 1

Re: [Mailman-Developers] Re: handle_opts.py
by donal.hunt2＠mail.dcu.ie 30 Aug '01

30 Aug '01

Marc, It's enough to just edit the *.py files afaik. When the file is next used by Mailman it will be recompiled into its *.pyc version. The files in ~mailman/cgi-bin are just wrappers for the *.pyc files in ~mailman/Mailman/Cgi Confusing at first, but very nice for maintenance and coding in new features. :) Thanks again for the pointers Barry... Donal ----------------------------------------------------------------------- Message: 12 Date: Thu, 30 Aug 2001 11:55:16 +0200 From: Marc Logemann <mlogemann(a)morelogs.de> To: mailman-developers(a)python.org Subject: Re: [Mailman-Developers] Re: handle_opts.py > You shouldn't need to recompile the binary, which is just a small C > wrapper that, through a little bit of -Dmacro magic gets compiled to > run Mailman/Cgi/handle_opts.py. Thus you could just do a make install > in Mailman/Cgi, although the .pyc files won't get compiled until you > actually hit the page (could mess with permissions a bit). i recently looked over the "subscribe.py" because of the html outputs (allready discussed that), and i had some problems to understand the meaning of the binary files. Up until now, i thought the function were in the binary, but later (of course after struggling with make install) i realized that its enough to edit the subscribe.py in order to have the changes. two basic questions: 1. the binary is only a wrapper w/o any functionality, so its basically only a redirector for the .pyc files? And i assume you use them for some kind of security reasons? 2. Does this mean that normally you dont have to struggle with the binary files? Or are there frequent needs to compile them after changes? Thx for info, i am quite new to python (programmed java and php the last t= wo years) and this compile in mailman/python thing was a miracle to me...I hope i ca= n contribute to mailman, its a nice piece of software. morelogs | Marc Logemann, chief evangelist ____________________________________________________________ Rellinghauser Str. 332 =B7 D-45136 Essen =B7 Germany T: +49 201 84 188-177 =B7 F: +49 201 84 188-199 mlogemann(a)morelogs.de =B7 http://www.morelogs.de

1 0

Re: [Mailman-Developers] Re: handle_opts.py
by Marc Logemann 30 Aug '01

30 Aug '01

> You shouldn't need to recompile the binary, which is just a small C > wrapper that, through a little bit of -Dmacro magic gets compiled to > run Mailman/Cgi/handle_opts.py. Thus you could just do a make install > in Mailman/Cgi, although the .pyc files won't get compiled until you > actually hit the page (could mess with permissions a bit). i recently looked over the "subscribe.py" because of the html outputs (allready discussed that), and i had some problems to understand the meaning of the binary files. Up until now, i thought the function were in the binary, but later (of course after struggling with make install) i realized that its enough to edit the subscribe.py in order to have the changes. two basic questions: 1. the binary is only a wrapper w/o any functionality, so its basically only a redirector for the .pyc files? And i assume you use them for some kind of security reasons? 2. Does this mean that normally you dont have to struggle with the binary files? Or are there frequent needs to compile them after changes? Thx for info, i am quite new to python (programmed java and php the last two years) and this compile in mailman/python thing was a miracle to me...I hope i can contribute to mailman, its a nice piece of software. morelogs | Marc Logemann, chief evangelist ____________________________________________________________ Rellinghauser Str. 332 · D-45136 Essen · Germany T: +49 201 84 188-177 · F: +49 201 84 188-199 mlogemann(a)morelogs.de · http://www.morelogs.de

1 0

[PATCH] Modifying #! env python line to match --with-python
by Ben Gertzfield 30 Aug '01

30 Aug '01

Many, many utility programs and other scripts that are in Mailman CVS have #! /usr/bin/env python hard-coded in them, and do not use the @PYTHON@ symbol exported from autoconf. This means that the --with-python flag cannot be ever used if python is not named "python"; for Debian Linux, this is a Big Problem, because the python 1.6 and python 2.0 binaries have different names. (/usr/bin/python vs /usr/bin/python2). So, I created a patch that makes building possible when python is called *anything*; I've tested it on Debian GNU/Linux unstable, where python is called python2, and it works. The patch (it's 500K, because it renames a lot of files) is available at: http://nausicaa.interq.or.jp/mailman/with-python.patch It does the following: 1) Defines a shell variable SCRIPTS in configure.in. This variable contains a list of scripts that are to be created from script.in templates; the only thing that we care about expanding is changing the first line, from: #! /usr/bin/env python to: #! /usr/bin/env @PYTHON@ This variable is passed in to AC_SUBST and AC_OUTPUT both, so that the top-level Makefile can do a 'rm -f ${SCRIPTS}' in its make distclean target. 2) Renames all the scripts that used the hard-coded name for python from (for example) bin/qrunner to bin/qrunner.in 3) Chmods 0755 all the generated scripts from the top-level Makefile, by adding a 'script-perms' target to the 'all' target. 4) Removes misc/mailman on a make distclean (this was auto-generated before but never removed on a make distclean, probably messed up some people's patches..) by editing misc/Makefile.in. This is totally unrelated to the other fixes but it's pretty obviously a minor bug. It would be trivial to move the SCRIPTS variable definition to a file outside of configure.in, if that's a cleaner way to maintain it in the future. There are some files in the Mailman CVS tree that have #! /usr/bin/env python lines, but are never really executed. I didn't munge these files, because forcing folks to guess that SOME files in the Mailman source tree are .in and others aren't is icky These files are: [ben@nausicaa:~/src/mailman/mailman]% find . -type f -print0 | xargs -0 grep -H '#!.*env.*python' ./Mailman/Post.py:#! /usr/bin/env python ./Mailman/Archiver/pipermail.py:#! /usr/bin/env python ./misc/Cookie.py:#!/usr/bin/env python If I'm wrong, and these should be included in the SCRIPTS variable, feel free to change the patch. But I excluded them for now. Here's the list of files I did include in the SCRIPTS variable. These are the ones that are renamed to (for example) contrib/rotatelogs.py.in by the patch and changed to use #! /usr/bin/env @PYTHON@ . contrib/rotatelogs.py contrib/qmail-to-mailman.py contrib/securelinux_fix.py filters/bowa-strip Mailman/pythonlib/mailbox.py cron/senddigests cron/bumpdigests cron/nightly_gzip cron/mailpasswds cron/gate_news cron/checkdbs admin/bin/Release.py admin/bin/mm2do admin/bin/faq2ht.py bin/update bin/newlist bin/check_perms bin/find_member bin/withlist bin/mailmanctl bin/change_pw bin/list_admins bin/check_db bin/list_lists bin/pygettext.py bin/qrunner bin/clone_member bin/genaliases bin/digest_arch bin/arch bin/rmlist bin/mmsitepass bin/version bin/remove_members bin/config_list bin/list_members bin/sync_members bin/add_members bin/dumpdb scripts/mailowner scripts/mailcmd scripts/post scripts/leave scripts/join scripts/auto src/setup.py Please let me know if there are any comments/suggestions. Now that I've got mailman building on Debian unstable, I can start testing the patch I made for avoiding duplicate mails. *grin* Ben -- Brought to you by the letters P and C and the number 1. "Ohhhh, Mentos Boy!" Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/

2 4

Re: [Mailman-Users] * Mailman Docs Moving *
by J C Lawrence 30 Aug '01

30 Aug '01

On Tue, 28 Aug 2001 12:04:00 -0500 Christopher Kolar <ckolar(a)aurora.edu> wrote: > Hello everyone. I will be changing jobs this week and the mailman > documentation will be moving with me. I will be looking through > my logs to see if I can find people who have incoming links but > things will be busy for me the next couple of days and I may note > be able to contact people in a timely fashion; so if you link to > the docs at www.aurora.edu/~ckolar/mailman please note that they > will now be at: > www.imsa.edu/~ckolar/mailman Would there be a problem with putting them directly on the Mailman site? -- J C Lawrence )\._.,--....,'``. ---------(*) /, _.. \ _\ ;`._ ,. claw(a)kanga.nu `._.-(,_..'--(,_..'`-.;.' http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly

5 8

Re: [Mailman-Developers] Preventing spam to list admins.
by J C Lawrence 30 Aug '01

30 Aug '01

On Mon, 27 Aug 2001 22:56:32 -0700 Chuq Von Rospach <chuqui(a)plaidworks.com> wrote: > On 8/27/01 10:14 PM, "J C Lawrence" <claw(a)kanga.nu> wrote: > I like the idea of having mail funnel through > listname-owner@domain, and have that point to the list of all > admins (or with 2.1, where we have list admins, content admins and > site admins, how weill this breakout change? Hmm). Seems to me > the answer is to bridge access to that address through some kind > of interface that spambots can't traverse, but humans can. That > would mean not putting mailtos on the page, but doing something > that would let the user mail the admin. I'm not necessarily a fan > of the "send email" form thing, either, since if mailman breaks, > that form also probably breaks (and how will they email us to tell > us It's broken?), but I'm not sure there's are many alternatives > that solve all of these problems... Okay, have the text on the page read listname-admin@domain, but have the link invoke a CGI which presents a form to write/send a message. > I do believe that shifting the listinfo page to be a mailto to the > -owner address will only get that address on the spam lists and > solve nothing.... I don't know that that problem is, or should be, resolvable. Humans need to see/get that address. That means that harvesters can too. >> There are two conflicting requirements here: >> >> 1) The list admin address needs to be cannonical, well known, and >> always supported. >> >> 2) We can't tell anybody about it. > Does it have to be well-known? Canonical? Yes, and yes. Users will know and learn the pattern, will expect it, and will use it (they do already). This is a Good Thing. > Or is it something that simply has to be available on request? Won't work if Mailman is down. The admin-address is specifically needed be direct. > There ARE addresses that have to be canonical and well-known, but > are list-admin addresses one of those? Or can we, say, generate > them dynamically or simply hide them through some accessible > interface? I don't believe so. >> What we can do is try and institute methods for sites to help >> them control the damage wreaked by #1. Sadly, I don't have a lot >> of suggestions there. other than the fact that doing away with #1 >> is not an acceptable answer. > The first answer is to run it all through whatever mailman uses > for anti-spam for the posting addresses. Which would at least > allow us to define auto-bounce rules for the "easy" stuff, like > pr0n, judicial judgements and the like. We could filter out the > "low hanging fruit" with a decent tool, if it filters admin mail > through it. > But that's only low hanging fruit. And a partial solution. But > it's a start. <nod> I'm leery of trying to do too much. We don't need to. If we do just enough and make it easy for others to follow, they can and will do the rest. We can then cherry pick. >>> armor we can give them in other ways. I don't think we can do >>> nothing, and I don't think the answer is "have them filter with >>> procmail"... >> Well, of course we can. Many do precisely this (little). Its >> just that we'd do better and be better if we didn't. Its more >> admirable to step up to the plate, even if you do miss the ball. > Or foul it off. Tell your admins running lists from AOL that all > they need to do is install procmail... > No, I think if we create a problem (and we are) we have some > responsibility to minimize it and do what we can about it. It > might not be easy for Mailman developers, but then, by the same > rationale, we could do away with subscription validation, no? You misunderstand. I'm agreeing with you above. -- J C Lawrence )\._.,--....,'``. ---------(*) /, _.. \ _\ ;`._ ,. claw(a)kanga.nu `._.-(,_..'--(,_..'`-.;.' http://www.kanga.nu/~claw/ Oh Freddled Gruntbuggly

6 20

customizing the listinfo page
by Paivi Salonen 30 Aug '01

30 Aug '01

hello has anyone modified the listinfo page to show all the lists so that the users can subscribe to as many lists as they want with one signup? example: http://e-newsletters.internet.com/discussionlists.html. the individual pages could still be there as they are now. i have looked at the source but i am 100% lost when it comes to python. and my boss wants it to work that way or we have to use something else.. i like mailman a lot and i dont want to give up. so.. anyone done this? or anyone willing to give it a try? paivi

1 0

Re: [Mailman-Developers] [PATCH] Modifying #! env python line to match --with-python
by Dan Mick 30 Aug '01

30 Aug '01

> I know it's easy to change those files, but what I don't want to do is > lose the CVS history of the files. If CVS had a "move" or "copy" > command, we'd be fine. It doesn't? Man, that bites.

2 1

Preferred Feedback Pipeline
by Ben Burnett 30 Aug '01

30 Aug '01

Hey Barry, I'm posting this on the list because I think it would be relevant for everyone to know. What is you're preferred pipeline for feedback on Mailman, especially feedback on testing the development releases? The reason I ask is that it seems that there are quite a few different places that could be used. The sourceforge site. bugs, patches, feature requests http://www.sourceforge.net/projects/mailman The discussion lists. much and many of everything. mailman-users(a)python.org, mailman-developers(a)python.org The wiki. requirements, architectural directions, component designs, more http://www.zope.org/Members/bwarsaw/MailmanDesignNotes/FrontPage Did I miss any? Perhaps you'd prefer a different venue and format for different types of feedback. While I don't expect to be able to have 100% of all feedback redirected perhaps if we put your preferred methods in the FAQ, README, and the devs.html, bugs.html, and todo.html pages of the Mailman site a good portion could be redirected. feature request: sourceforge? bug report: sourceforge? patches: sourceforge? usage questions: mailman-users? development questions: mailman-developers, wiki? praise: ? rant's, demands, whining: /dev/null? money: ? Am I making an issue out of a non-issue? - Ben

3 2

Handling Bouncebacks
by James Leone 30 Aug '01

30 Aug '01

I'm interested in understanding how Mailman handles bounces and seeing if my previous MLM experience will allow me to make additions. I'm fresh to Python, but am familiar with Perl as well as Java and feel compfortable looking at the code, but need some reinforcement at the higher level of architecture. These questions should be easy. The email blast goes out and the bads ones come back to a specified address. Does Mailman run as a daemon or are bouncebacks handles by piping through the aliases file? Basically, where is the entry point for disecting the message and determining whether is looks like a bounced email or the user's mailbox is just full. I see that there is a Bouncer class, and an example api, but the comments are rather sparse. __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/

4 4