Mailman 3 September 2000 - Mailman-Users

Too many pending requests?
by Per Starback 07 Jul '03

07 Jul '03

I can't get to the pending request page for a mailing list. (My web clients just say "waiting for response" and finally give up.) I think it is because there are too many pending requests after some problems. (config.db is almost 10MB.) How can I do this some other way?

5 5

Re: [Mailman-Users] searching archives
by J C Lawrence 26 Oct '00

26 Oct '00

On Sat, 23 Sep 2000 22:25:38 -0400 Aaron Titus <titus(a)ncat.edu> wrote: > I'd like to make public mailman archives searchable. What is the > best way to do this? I use UdmSearch as an esternal archiver: http://www.kanga.nu/search/ Another common choice HT:Dig, or if your loads are light enough that you can afford to do realtime searches (ir no pre-genned indexes) things like Swish. There have been previous discussions (and patches I think) to support having Pipermail emben the appropriate HTML for your search interface, but I've not looked into that as I use MHonArc as an external archiver: http://www.kanga.nu/archives/ Archive configs: ftp://ftp.kanga.nu/pub/Kanga.Nu/WebArchives/ And an older simpler form: ftp://ftp.kanga.nu/pub/Kanga.Nu/WebArchives.old/ -- 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 |=--

2 1

Re: [Mailman-Users] Multiple domain lists
by Nigel Metheringham 02 Oct '00

02 Oct '00

chris(a)gwydion.net said: > I have another domain, bar.com, which has an Apache vhost properly > configured etc, and all that. Exim will handle mail for bar.com. > How to I make mailman establish the list fubar(a)bar.com? For a small number of domains with unique listnames - ie listname(a)foo.com & listname(a)bar.com being the same list is not a real problem to you, you can just set the domain name in the list config and things work correctly - including by the way http://www.foo.com/mailman/ listinfo/ only listing the lists that match that domain. This is exactly what I do with the exim.org box which has a few other personalities. Distinct listnames can be done by one install of mailman per domain (this might actually be a virtualised install where its mostly symlinked - there is a partial mention of this in the exim/mailman howto. Real management of multiple virtual domains is something for the future... you also need to remember that there may be multiple near identical mail domains (I accept mail for www.exim.org as well as exim.org). 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 ]

5 4

Postfix Virtual Domains Problem
by David Wilkinson 30 Sep '00

30 Sep '00

I'm having problems with Mailman 2.0beta6 running under a postfix virtual domain. With Postfix's main domain, everything works fine, but if I configure Mailman to operate under one of the virtual domains I observe two problems: - Mailing lists with 'member_posting_only' set will accept posts from anybody - No list archives are created The only difference that I can see in the configuration is that in this case I have an entry in virtual_maps for the virtual domain which point to a file containing lines of the form: list(a)virtual.domain virtual.list(a)main.domain and then I have a mailman-owned alias file which has the usual: virtual.list: "|/home/mailman/virtual.domain/mail/wrapper post list etc. Mail does get distributed to list members as expected, but this extra level of indirection seems to break member_posting_only and archiving. Does anyone have Mailman working properly with Postfix? Any suggestions as to what I'm doing wrong? Thanks, Dave W. -- David Wilkinson http://www.cascade.org.uk/

1 0

Installation question
by Dale M. Grantham 29 Sep '00

29 Sep '00

I have a question using mailman with sendmail on a Solaris 2.6 box. Upon sending to test-request or test-owner, I get the following error: 553 ruger. config error: mail loops back to myself 554 <test-owner(a)ruger.ptc.com>... Local configuration error If I send a message to test, nothing (at least to me) happens. I know qrunner is running (via log file). Where do the request queue up, and can I check the status somewhere? Dale.

1 0

new mailman installation
by Rick Pasotto 29 Sep '00

29 Sep '00

I am running a debian-linux system and want to set up some mailman mailing lists. Should I (1) go ahead and start the lists using 1.1 and then upgrade when 2.0 becomes final, (2) install 2.0beta as a starting point, or (3) wait until 2.0 becomes final to start the lists? Is the upgrade expected to be relatively painless? -- "Anarchism is founded on the observation that since few men are wise enough to rule themselves, even fewer are wise enough to rule others." -- Edward Abbey Rick Pasotto email: rickp(a)telocity.com

3 2

BUG? Problem with subscribing to a list via web.
by Ray Frush 29 Sep '00

29 Sep '00

I've installed 2.0 beta 6 and I am using the web interface to subscribe to a list. I've noticed the following problem: The server is ale.ftc.agilent.com and the list is "test"... If I subscribe to the list and enter "user(a)ftc.agilent.com" the message sent to confirm the subscription has the headers: From: test-request(a)ftc.agilent.com To: user(a)ftc.agilent.com Reply-To: test-request(a)ftc.agilent.com The problem here is that ftc.agilent.com does not understand "test-request" and won't route the message to ale.ftc.agilent.com. If I subscribe with the address "user(a)ale.ftc.agilent.com" the Confirmation message shows: From: test-request(a)ale.ftc.agilent.com To: user(a)ale.ftc.agilent.com Reply-To: test-request(a)ale.ftc.agilent.com If I subscribe with the address "first_last(a)agilent.com" the Confirmation message shows: From: test-request(a)ale.ftc.agilent.com To: first_last(a)agilent.com Reply-To: test-request(a)ale.ftc.agilent.com In the above cases, the reply-to gets routed properly (because it has the full hostname.) So, is the first case by design? or is there a bug here? -- Ray Frush "Either you are part of the solution, T:970.288.6223 or part of the precipitate." -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Agilent Technologies IT | Consumer and Site Services | Fort Collins Site

1 0

Problem with cookies in 2.0beta6
by Thomas Chiverton 29 Sep '00

29 Sep '00

I'm new to this, and the FAQ is a little small, so excuse me :-) I create a new list with bin/newlist and go to the URL it emails me (... /mailman/admin.cgi/test). I enter the password, and Netscape warns me it's excepting a cookie, which I except, and it stores it in ~/.netscape/cookies as normal. I change somoe settings, press the submit button and it returns me to the login prompt. If I type the password in again, my changes have vanished. MailMan 2.0beta6 (installed as mailman:mailman) Apache 1.3.9 (running as www:http) Python 1.5.2 ((#1, Feb 18 2000, 00:56:30) [GCC 2.95.2 19991024 (release)] on sunos5) I've installed exactly as per the INSTALL instructions, clean install. Any clues what might be up ? -- Thomas Chiverton, systems admin. and WebMaster thomas(a)grenville.co.uk or phone 01565 757 909 (mobile 07967672404) For in-house IT issues, please mail helpdesk-submit(a)grenville.co.uk GnuPG: E86F DCC6 951A D17F FE6D 6299 21EE 650C 6DB0 B0ED

1 0

RE: [Mailman-Users] bad Reply-To in subscription confirmation
by Richard Barrett 29 Sep '00

29 Sep '00

Tokio Kikuchi <tkikuchi(a)is.kochi-u.ac.jp> has posted the solution to this problem. I've posted the fix as the following patch on sourceforge: https://sourceforge.net/patch/?func=detailpatch&patch_id=101701&group_id=103 Tokio Kikuchi <tkikuchi(a)is.kochi-u.ac.jp> said >Hi, > >I think I traced a bug in 2.0beta6 > >in Mailman/Handlers/CookHeaders.py > > > # > > # Reply-To: munging. Do not do this if the message is "fast tracked", > > # meaning it is internally crafted and delivered to a specific user, > > # or if there is already a reply-to set. If the user has set > > # one we assume they have a good reason for it, and we don't > > # second guess them. > > if not fasttrack or msg.get('reply-to'): >this line should be > if not fasttrack and not msg.get('reply-to'): > >Sorry but I have no time to use diff. > >This bug caused confirm message to go list address >in some cases (cf. -users discussion) > >Tokio >Hi > >Yup, > >it also fails under email type subscriptions. > >Ie if the reply_goes_to_list option is set to this list then a user cannot >simply reply as the reply-to header is not set correctly. > >I will try and figure it out, but being a novice at python etc I may not >come up with the goods :( > > > > >Best regards > >DBs >Technical Director >http://www.BarrysWorld.com >ICQ: 2261786 > > > > -----Original Message----- > > From: Richard Barrett [mailto:R.Barrett@ftel.co.uk] > > Sent: Friday, September 29, 2000 11:10 AM > > To: DBs (Mailing List) > > Subject: RE: [Mailman-Users] bad Reply-To in subscription confirmation > > > > > > I'm running 2.0beta6. > > > > I have found a definite bug (or is it a feature?) in the headers of > > outgoing confirmation requests. > > > > It appears that if: > > > > 1. The user is trying to subscribe from the web interface. > > > > 2. The reply_goes_to_list option on the General Options of a list is > > set to "This list" or "Explicit address" rather than poster then a > > Reply-To header is inserted. > > > > When the subscribing user tries to confirm by doing a simple reply, > > the reply does not get sent to the <list name>-request mail name but > > to the <list name> mail name of the explicit address. > > > > This problem may also appear with majordomo style mail subscriptions, > > I haven't checked that scenario yet. > > > > I'm trying to ascertain exactly why the insertion of the Reply-To > > header is not suppressed when the outgoing confirmation request is > > generated. If nobody else beats me to it I'll try and generate a > > patch to correct this. That is, unless somebody posts a convincing > > denial of the problem I'm seeing. > > > > > > "DBs (Mailing List)" <dbsml(a)barrysworld.com> said: > > >I too get this. > > > > > >If you subscribe over the web interface the reply-to address is set > > >correctly to listname-request. If you do it via email the > > -request part is > > >omitted. > > > > > >Spent hours looking thru the python source, but being a non-python user, > > >achieved not a lot :) > > > > > > > > >Best regards > > > > > >DBs > > >Technical Director > > >http://www.BarrysWorld.com > > >ICQ: 2261786 > > > > > > > > > > -----Original Message----- > > > > From: mailman-users-admin(a)python.org > > > > [mailto:mailman-users-admin@python.org]On Behalf Of Chad Jones > > > > Sent: Thursday, September 28, 2000 4:54 PM > > > > To: mailman-users(a)python.org > > > > Subject: [Mailman-Users] bad Reply-To in subscription confirmation > > > > > > > > > > > > Below is the header of a subscription confirmation email, > > the kind you get > > > > when you subscribe via email. The reply is supposed to go > > to the -request > > > > address but there's a Reply-To which directs the reply to > > the regular list > > > > address, which triggers the "moderator approval." > > > > > > > > Is there a way to fix this or can I just turn off the > > confirmation option? > > > > I have about 100 new users who are going to try to subscribe > > today and it > > > > would be nice if I could get this to work. I'm using mailman 2.0b6. > > > > > > > > Here is the header: > > > > > > > > Return-Path: <advisors-admin(a)lists.centerx.gseis.ucla.edu> > > > > Received: from norbert.gseis.ucla.edu (149.142.5.98) by > > tep.gseis.ucla.edu > > > > with > > > > ESMTP (Eudora Internet Mail Server 2.2.2); Thu, 28 Sep 2000 > > > > 08:34:52 -0700 > > > > Received: from norbert.gseis.ucla.edu (mailman@localhost [127.0.0.1]) > > > > by norbert.gseis.ucla.edu (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) > > > > with ESMTP > > > > id IAA00370 > > > > for <xlists(a)tep.gseis.ucla.edu>; Thu, 28 Sep 2000 08:37:01 -0700 > > > > Date: Thu, 28 Sep 2000 08:37:01 -0700 > > > > Message-Id: <200009281537.IAA00370(a)norbert.gseis.ucla.edu> > > > > Subject: advisors -- confirmation of subscription -- request 661850 > > > > From: advisors-request(a)lists.centerx.gseis.ucla.edu > > > > To: xlists(a)tep.gseis.ucla.edu > > > > X-Ack: no > > > > Sender: advisors-admin(a)lists.centerx.gseis.ucla.edu > > > > Errors-To: advisors-admin(a)lists.centerx.gseis.ucla.edu > > > > X-BeenThere: advisors(a)lists.centerx.gseis.ucla.edu > > > > X-Mailman-Version: 2.0beta6 > > > > Precedence: bulk > > > > Reply-To: advisors(a)lists.centerx.gseis.ucla.edu > > > > List-Help: > > > > <mailto:advisors-request@lists.centerx.gseis.ucla.edu?subject=help> > > > > List-Post: <mailto:advisors@lists.centerx.gseis.ucla.edu> > > > > List-Subscribe: > > > > <http://lists.centerx.gseis.ucla.edu/mailman/listinfo/advisors>, > > > > ><mailto:advisors-request@lists.centerx.gseis.ucla.edu?subject=subscribe> > > > List-Id: <advisors.lists.centerx.gseis.ucla.edu> > > > List-Unsubscribe: > > > <http://lists.centerx.gseis.ucla.edu/mailman/listinfo/advisors>, > > > ><mailto:advisors-request@lists.centerx.gseis.ucla.edu?subject=unsubscribe> > > > List-Archive: http://lists.centerx.gseis.ucla.edu/pipermail/advisors/ > > > > > > > > > ------------------------------------------------------ > > > Mailman-Users maillist - Mailman-Users(a)python.org > > > http://www.python.org/mailman/listinfo/mailman-users > > > > > > > > >------------------------------------------------------ > >Mailman-Users maillist - Mailman-Users(a)python.org > >http://www.python.org/mailman/listinfo/mailman-users ------------------------------------------------------------------ Richard Barrett, PostPoint 27, e-mail:r.barrett@ftel.co.uk Fujitsu Telecommunications Europe Ltd, tel: (44) 121 717 6337 Solihull Parkway, Birmingham Business Park, B37 7YU, England "Democracy is two wolves and a lamb voting on what to have for lunch. Liberty is a well armed lamb contesting the vote." Benjamin Franklin, 1759 ------------------------------------------------------------------

1 0

Reply-To bug
by Tokio Kikuchi 29 Sep '00

29 Sep '00

mailman-users-request(a)python.org wrote: > > > ------------------------------------------------------------ > > Subject: RE: [Mailman-Users] bad Reply-To in subscription confirmation > Date: Fri, 29 Sep 2000 11:10:09 +0100 > From: Richard Barrett <R.Barrett(a)ftel.co.uk> > To: mailman-users(a)python.org > > I'm running 2.0beta6. > > I have found a definite bug (or is it a feature?) in the headers of > outgoing confirmation requests. > > It appears that if: > > 1. The user is trying to subscribe from the web interface. > > 2. The reply_goes_to_list option on the General Options of a list is > set to "This list" or "Explicit address" rather than poster then a > Reply-To header is inserted. > > When the subscribing user tries to confirm by doing a simple reply, > the reply does not get sent to the <list name>-request mail name but > to the <list name> mail name of the explicit address. > Try this: in Mailman/Handlers/CookHeaders.py > # > # Reply-To: munging. Do not do this if the message is "fast tracked", > # meaning it is internally crafted and delivered to a specific user, > # or if there is already a reply-to set. If the user has set > # one we assume they have a good reason for it, and we don't > # second guess them. > if not fasttrack or msg.get('reply-to'): this line should be if not fasttrack and not msg.get('reply-to'): Sorry but I have no time to use diff. Tokio

1 0