Mailman 3 May 2000 - Mailman-Developers

pipermail/hypermail mbox-archive
by Thomas Wouters 01 Jun '00

01 Jun '00

There was a short discussion a month or so ago about the hyperarch 'mbox' archives having the wrong kind of date in the 'From ' lines... 'unixfrom' lines should have a very specific dateformat, namely that which 'time.ctime' returns. The following patch fixes Archiver/HyperArch.py. However, I'm not entirely sure if it will work correctly in other locales... can anyone test that, and propose a locale-independant way of producing this format ? Grtz, -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

2 3

CVS: mailman/Mailman ListAdmin.py,1.33,1.34
by Fil 01 Jun '00

01 Jun '00

It works great! Two cents= * in order to still have a responsive server, you need qrunner to be activated every minute or every other minute, not just every half hour like it is now (usually). * nothing is logged into /logs/* when a message is approved. Very stressfull for the mailman-master trying to watch if it works. S/he has to think to look at qfiles/ to see if the message was correctly processed. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Date: Tue, 30 May 2000 22:36:43 -0700 From: Barry Warsaw <bwarsaw(a)slayer.i.sourceforge.net> To: mailman-checkins(a)python.org Subject: [Mailman-checkins] CVS: mailman/Mailman ListAdmin.py,1.33,1.34 Update of /cvsroot/mailman/mailman/Mailman In directory slayer.i.sourceforge.net:/tmp/cvs-serv13283 Modified Files: ListAdmin.py Log Message: __handlepost(): Instead of trying to deliver approved messages immediately with DeliverToList(), enqueue the message for later delivery by qrunner. This vastly improves the responsiveness of the web interface for huge lists.

3 5

approved messages in 2.0beta3 not archived
by Mentor Cana 31 May '00

31 May '00

Hello, Some testing with 2.0beta3 revealed that the approved message are not being archived properly. Actually, the messages get into the list.mbox file but they are missing the "From " line and therefore do not show on the archive page. later, Mentor

3 2

Re: [Mailman-Developers] .nfs* lock files
by Harald Meland 31 May '00

31 May '00

[Melissa G. Ng] > I think it may be related to a problem I have regarding the cgi > script "listinfo". I don't think so. > When I try to invoke "<mailman-server>/mailman/listinfo" I get [...] > File "/user/mailman/Mailman/MailList.py", line 812, in Load > dict = marshal.load(file) > MemoryError: [...] > But when I invoke the individual lists's "listinfo" page, it comes > back fine. I think one of your lists have had its config.db corrupted (but I don't know _why_ that has happened). If so, you can discover which list is causing you grief like this: $ whoami mailman $ cd $ python Python 1.5.2 (#6, Dec 1 1999, 20:04:16) [C] on sunos5 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> from Mailman import Utils, MailList >>> for name in Utils.list_names(): ... print "About to attempt load of list", name ... mlist = MailList.MailList(name, lock=0) ... About to attempt load of list list1 [...] About to attempt load of list corrupt-list Traceback (innermost last): ... indicating that the corrupted list is called "corrupt-list". As the test aborts once a corrupt list is found, make sure you re-run the test until it finishes without producing any tracebacks. > Could someone please help me out with this problem? This isn't really on topic for this list -- the correct list for such problems is mailman-users. Cheap shot at making this post on-topic: Should there be a cron script (possibly cron/checkdbs will do) to warn the site admin about lists that have been corrupted? -- Harald

2 1

Re: [Mailman-Developers] CVS: mailman/Mailman ListAdmin.py,1.33,1.34
by Nigel Metheringham 31 May '00

31 May '00

fil(a)orwell.bok.net said: > The actual current cron/crontab.in says the following: > # Every 10 minutes retry failed deliveries. 02,12,22,32,42,52 * * * * / > usr/bin/python /var/lib/mailman/cron/qrunner > It should be > # Every minute try pending deliveries. * * * * * /usr/bin/python /var/ > lib/mailman/cron/qrunner Could you check that its happy if there are overlapping queue runner jobs. Also what happens if the MTA has been shut down? Things like this can be a real pain to deal with if you have to reboot a server and a last gasp cron job throws away mail because it fired up after the mta had stopped but before cron has been shut down... or various other scenarios. 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 ]

4 3

SMTPDirect.py and logs/post
by Gergely Madarasz 31 May '00

31 May '00

Hello, I just noticed that the SMTPDirect.py does not log to logs/post... so no more easy statistics... -- Madarasz Gergely gorgo(a)sztaki.hu gorgo(a)linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/

3 5

Re: [Mailman-Developers] Q: Security checking in wrappers and config file
by Harald Meland 30 May '00

30 May '00

[Michael Tokarev] > I looked to mailman wrappers code, and found that it performs some > strange to me fings. First of all, it is seemed to be not good idea > to define uids/gids as numbers inside executable wrappers (for mail > and www). These values are derived from whatever GIDs the configure script finds. You can specify what group name to use with the "--with-mail-gid" and "--with-cgi-gid" configure options. > I think that something caused the current approach when the code was > developed, but don't know what it was... > > Why not use the following schema: > > * made one config file in well-known place (e.g. /etc/mailman.conf) > and require that it writable only by root (maybe) > * place all the info there (including mail gid, www gid, > location of mailman "home" directory etc. (the last one > will be PYTHON_PATH; also, it can be read using getpwnam) Why? What does this win us over the situation we have now? The only "advantage" I can see is that you wouldn't have to recompile Mailman if some of the GIDs Mailman is invoked from change; editing the config file will suffice. However, is that really a common enough occurence that we'd want to require a separate config file for it? > * do not rely on setgid for mailman home, but instead use real > setgid calls Ummm, I don't think I understand what you mean... > With current layout, it is not possible to split programs and data. Not quite true; you can fake a split by substituting symlinks for the subdirs under $(prefix). > I want to put all executables into, say, /usr/mailman, and all data > to /var/[spool/]mailman and /var/log/mailman (and mount /usr > read-only). Having config file it is simple. > > Also, with current approach, many files will be owned by some > strange users when mailman operates. For example, config.db file > owned by nobody (run from www) or whatether owner when run from MTA, > the same cab be with logs. This is potentially unsecure, as, e.g., > any other cgi script can read _and_ write this config file as a > result, not only mailman group. Yes, rewriting is not very good > (not an atomic operation), but I prefer security here... Ummm, I still don't follow you -- are you saying that we should use setuid instead of setgid stuff? As for other cgi scripts being able to write lists' config.db files: Unless your web server user is a member of the mailman group, non-mailman-setgid cgi scripts may be stopped from accessing Mailman-internal data by chgrp mailman $(prefix)/lists chmod o-rwx $(prefix)/lists etc. (I think -- this is untested). > And some more thoughts. > Many MTAs sets environment variables when delivering to programs. > For example, postfix sets LOGNAME to recipient name, DOMAIN to > part of recipient address after @, FROM to envelope address > and so on, and those variables are _safer_ to use (in case of > postfix) than information from mail contents (with both sides -- > MTA can have more info available about real person who sends this > mail, based on, say, smtp AUTH commands, and, in case of postfix, > those values are already parsed by intelligent mechanism and with > all strange/funny/control characters removed). > Is it possible candidate to enhancement to include usage of those > variables? Only if it would be a) safe and b) not too MTA-specific. In the example you provide, I don't think those two criteria are satisfied -- I'd either have to _explicitly_ tell Mailman that the MTA delivering to it is Postfix, or risk using heuristics to determine what MTA is doing the delivery. I suppose heuristics might easily be fooled if I pass similar environment variables on to e.g. an Exim daemon. > P.S. I'm new to this list... :) Welcome! Hopefully me being rather sceptic to the changes you are proposing aren't ruining the first impression ;) -- Harald

3 2

Re: [Mailman-Developers] sort by thread for digest mode in mailman?
by J C Lawrence 30 May '00

30 May '00

On Tue, 30 May 2000 15:54:56 -0400 (EDT) Jim Hebert <jhebert(a)jhebert.cx> wrote: > obJustifyPostingToWholeList: any pointers to learn more about work > along these lines (e.g., mailers that are beginning to integrate > support for this, discussion of the emerging standards, etc)? The RFCs defining MIME digests have been around a couple years. For commercial MUAs, as MIME digest support doesn't really impact the delivery of pictures of naked women on pink slips to people's desktops there hasn't been a lot of commercial impetus to improve that area of MIME support. The driving force left is that of checkbox items for maketting use. Conversely, in the Open Source arena, full, or at least workable support for MIME digests or RFC 1163 digests 9which is as plain text format, and not what Mailman uses (tho it should) is quite common: eg Mutt, Gnus, Exmh (wot I use), etc. -- J C Lawrence Home: claw(a)kanga.nu ----------(*) Other: coder(a)kanga.nu --=| A man is as sane as he is dangerous to his environment |=--

1 0

Re: Approval bug in 2.0b3 (fixed)
by Ron Jarrell 30 May '00

30 May '00

Ok, I went digging through the code (I've really got to learn more Python). It looks like the def for HanderAPI.DeliverToList got changed, but the instance where ListAdmin.py uses it didn't. Or ListAdmin.py got changed, but HandlerAPI hasn't caught up? Dunno. ListAdmin assumes the third arg is a newdata= format, but the API just shows the third arg as msgdata. So I made this patch, and suddenly all the admindb approval stuff is working again: Index: ListAdmin.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/ListAdmin.py,v retrieving revision 1.32 diff -c -r1.32 ListAdmin.py *** ListAdmin.py 2000/05/22 21:37:05 1.32 --- ListAdmin.py 2000/05/30 21:23:38 *************** *** 180,186 **** msg = Message.Message(fp) msgdata['approved'] = 1 # ignore return value ! HandlerAPI.DeliverToList(self, msg, newdata=msgdata) elif value == 1: # Rejected rejection = 'Refused' --- 180,186 ---- msg = Message.Message(fp) msgdata['approved'] = 1 # ignore return value ! HandlerAPI.DeliverToList(self, msg, msgdata) elif value == 1: # Rejected rejection = 'Refused'

2 1

Mailman 2.0 forgets 'To:' field in notification messages
by Marc MERLIN 30 May '00

30 May '00

Mailman used to send messages with a To: field, but the 2.0 betas have dropped that unfortunately. It should only be a 2mn change or so for someone used to the mailman code. If no one has the time to do it (i.e. no one answers), I'll give it a shot in a week or so. Thanks, Marc ----- Forwarded message from mailman-owner(a)merlins.org ----- Date: Tue, 30 May 2000 01:11:54 -0700 From: mailman-owner(a)merlins.org Subject: Empeg-general subscription notification X-BeenThere: empeg-general(a)empeg.merlins.org X-Mailman-Version: 2.0beta3 Precedence: bulk List-Id: General Discussion for Empeg Users <empeg-general.empeg.merlins.org> ccarroll(a)nationwide.net has been successfully subscribed to Empeg-general. ----- End forwarded message -----

2 1