Mailman 3 March 2002 - Mailman-Developers

RFE: configurable bounce message
by Marc MERLIN 30 Mar '02

30 Mar '02

I had to modify the string Moderate.py to give a more appropriate reject message. Ideally this should be a string per list. ----- Forwarded message from svlug-owner(a)svlug.org ----- Subject: test 3 From: x To: y You are not allowed to post to this mailing list without being subscribed, and your message has been automatically rejected. You should subscribe to the list to be able to post. If you think that you messages are being rejected in error, contact the mailing list owner at svlug-owner(a)lists.svlug.org. (...) ----- End forwarded message ----- -- 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

1 0

Problem with substitution of %(listname)
by Ellen Spertus 30 Mar '02

30 Mar '02

I created a new list named "Sys". When I subscribe and confirm by web, I get the following web page. Note the "%(listname)s" on the second line. Awaiting moderator approval You have successfully confirmed your subscription request to the mailing list %(listname)s, however final approval is required from the list moderator before you will be subscribed. Your request has been forwarded to the list moderator, and you will be notified of the moderator's decision. -------------------------------------------------------------------------------- Sys list run by spertus at mills.edu Sys administrative interface (requires authorization) Overview of all javamlm.mills.edu mailing lists Later substitutions (such as at the foot of the page) are successful. When I look at the list directly in Python, it seems to be okay: >>> sys <mailing list "sys" (unlocked) at 82fb764> >>> sys.real_name 'Sys' >>> sys._internal_name 'sys' I'm using Mailman 2.1a3. Any ideas what could be wrong? Ellen

1 0

Re: [Mailman-Developers] traceback (still due to the BounceRunner)
by J C Lawrence 30 Mar '02

30 Mar '02

On Fri, 29 Mar 2002 11:15:59 +0100 fil <fil(a)rezo.net> wrote: > From what I see it needs about 5-6 seconds (on a 50000 subscribers' > list) to process and register one bounce. So it really shouldn't > process more than 4 in a row (ie in a minute) if we want the lockfile > to be released before 30 secs. However that would mean processing 4 > bounces per minute. If you have 50 000 bounces, that's 12 500 > minutes... not good. I don't know what to suggest, except maybe to > make a BounceRunner preprocessor that doesn't read or write the list > files, but just extracts the bounce information and gets rid fast of > the bounce files. Then for the "real" BounceRunner to process the > bounce information already computed would be very fast. Bounce processing really needs to be abstracted into a two pass process. Due to its current ad-hoc nature load and lookup expense for processing the membership roster is dominating the equation. Suggest: One pass does nothing but parse the incoming bounces for addresses and then adds them to a local/shared DB. An infrequently run cronjob (suggest no more than a couple times a day), then picks up this DB and handles the removals in a single fast locked process. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw(a)kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.

1 0

Re: [Mailman-Developers] "search for member with RE" box at top instead of bottom
by Dan Mick 29 Mar '02

29 Mar '02

> See what you think about this (against cvs)... Very nice; thank you.

1 0

install trouble
by Ron Jarrell 29 Mar '02

29 Mar '02

Interesting... Didn't have this trouble on my test solaris box, but on my prod solaris box, with a neigh unto identical config (other than sol 8 vs 7) I'm having the "wanted gid 30, got gid 1" Mailman appears to have properly sussed out that my mailman group is 30, and, in fact, installed mailman setgid to mailman, but suddenly it's not actually taking that gid.

3 7

bin/qrunner picking up changes
by Mentor Cana 29 Mar '02

29 Mar '02

With the latest CVS, whenever list's configuration changes (i.e. new headers or footers) a bin/mailmanctl restart is needed. This could confuse lists owners who expect (rightfully so) to see the changed footers or headers on their lists as soon as they save the configuration. Should the "Submit Your Changes" button do a "bin/mailmanctl restart" after successfully saving list's changes? (I'm not sure of this behavior is limited to headers and footers only) -- Mentor

4 4

A quick thank you
by Vladimir G. Ivanovic 29 Mar '02

29 Mar '02

After struggling with Majordomo(*), a heartfelt thanks to all for making mailing lists so painless. I was up and running in minutes. --- Vladimir (*) Majordomo was wonderful in its day, but clearly its day is past. -------- Vladimir G. Ivanovic http://leonora.org/~vladimir 2770 Cowper St. vladimir(a)acm.org Palo Alto, CA 94306-2447 +1 650 678 8014

1 0

important VERP safety tip...
by Ron Jarrell 29 Mar '02

29 Mar '02

Important thing to remember (and probably something that ought to go into the faq, or the readme, or somewhere, or even into Defaults.py)... If you change your VERP options, do a mailmanctl restart so that the damn queuerunners will re-read mm_cfg.py... Unless you *like* chasing your tail for a couple of hours.

2 1

Re: [Mailman-Developers] qrunner fails to start on 2.1b4
by barry＠zope.com 29 Mar '02

29 Mar '02

>>>>> "BD" == Brett Delmage <brett(a)twobikes.ottawa.on.ca> writes: BD> I updated from 2.1a4 to 2.1b1 this weekend. SuSE 7.3, python BD> 2.1.1 BD> A problem showed up during make install, where paths.py was BD> not copied into the bin, scripts, cron directories. Okay, you need to figure out why paths.py wasn't copied. It may be a permission problem, or it may be something deeper. I definitely haven't seen this myself, so something weird's going on with your environment. BD> I copied it in manually and that cleared the initial problems: BD> the Cgi parts seemed to work (without exhaustive testing). BD> Now I'm running into the followuing problems with qrunner but BD> I am not sure where to look. Suggestions? It looks like it BD> might still be related to paths.py? Very likely, although if bin/qrunner (which is what spits out these errors) couldn't import Mailman.Queue.* via the __import__() call in make_qrunner() , then how did it get far enough to import the various modules at the top of the file? Very strange. -Barry

1 0

Re: [Mailman-i18n] korean translation
by barry＠zope.com 29 Mar '02

29 Mar '02

>>>>> "MvL" == Martin von Loewis <loewis(a)informatik.hu-berlin.de> writes: MvL> Then please take my apologies: from your response, I assumed MvL> that you would indeed co-maintain mailman. My original MvL> question remains, though: MvL> Is anybody considering these patches (not just my own; I MvL> notice that the oldest patch which had no review is dated MvL> 2000-09-21)? At present, I'm really the only one actually committing changes to cvs, although several people (Ben, Dan and Daniel, Ron, etc.) do provide very excellent patches. You too Martin. But this means I'm the bottleneck for getting fixes in, and that's subject to the vagaries of my "real" job. ;) One way to help out right now: I can add you as a tracker admin and you can help do triage on the bugs and patches. This actually would be an enormous help, because there's a lot of things to go through. Even weeding out those issues that are no longer relevant for MM2.1, and assigning everything that's left to me would help a lot. I'd also love it if someone would take responsibility for Pipermail. As crufty as it is, it's all we have, and it's good enough for many people. But it's a complicated system that needs its own steward. Anybody willing to put the time and effort into it, I'd be happy to add as a cvs committer (although we have to watch out about GNU issues -- but several people have already assigned their future changes to the FSF). As for the core system, I admit to being protective of it. I'm willing to loosen my grip if it helps Mailman development move along faster. There are folks in the community who know enough about the system, and whom I trust to make changes to the code. -Barry

1 1