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?
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 |=--
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 ]
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/
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.
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
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
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
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
------------------------------------------------------------------
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
