Mailman 3 November 2004 - Mailman-Developers

RE: [Mailman-Developers] Min requirements for running Mailman?
by John.Airey＠rnib.org.uk 31 May '05

31 May '05

> -----Original Message----- > From: mailman-developers-bounces+john.airey=rnib.org.uk(a)python.org > [mailto:mailman-developers-bounces+john.airey=rnib.org.uk@pyth > on.org]On > Behalf Of Tollef Fog Heen > Sent: Monday, 06 September 2004 16:47 > To: mailman-developers(a)python.org > Subject: Re: [Mailman-Developers] Min requirements for > running Mailman? > > > * Nigel Metheringham > > | I'd tend to take this as:- > | * Mailman is a bitch to package > > Not really. It's fairly well-behaved in my experience. It's a > semi-large web application with some requirements, but nothing > unreasonable. > > | * RH have packaged it for a while > | * RH found a good few of the gotchas in packaging Mailman > | * RH have subsequently learnt from their mistakes and recently > | have produced good packages. > | * Other distros may do better, or may yet have to > learn from their > | mistakes :-) > > Mailman has been in Debian since June 1998 (1.0b4), so we've been > working on it for a while as well. I think our packages are of good > quality (far from perfect, but making perfect packages is _a lot_ of > work. ;) > Just to throw my tuppence worth in... I've used mailman since Red Hat 7.2. I found that the version that came with Red Hat 9.0 wouldn't work for me (ie I couldn't upgrade to it) so I stuck with the 7.2 version (2.0.13) till the end of Red Hat 9 support. We are now running the 2.1.5 version that comes with Fedora but running it on Red Hat Enterprise Linux (RHEL). I did however have to recreate all the lists by hand in an overnight shift (what fun that was...) a few days before leaving the country (hence the rush). At that time I didn't know I could export the configuration (Doh!). Red Hat have taken some packages out of RHEL eg arpwatch and mysql-server (although this is in the "extras" channel) even though these are in the source RPM. Mailman is currently not included but might be being put back in to RHEL 4.0. I would like to hope so, as I find 2.1.5 far superior to 2.0.13. -- John Airey, BSc (Jt Hons), CNA, RHCE Internet systems support officer, ITCSD, Royal National Institute of the Blind, Bakewell Road, Peterborough PE2 6XU, Tel.: +44 (0) 1733 375299 Fax: +44 (0) 1733 370848 John.Airey(a)rnib.org.uk To truly believe in Evolution requires complete faith that life has no meaning. Fortunately there are billions of people who aren't that stupid. -- DISCLAIMER: NOTICE: The information contained in this email and any attachments is confidential and may be privileged. If you are not the intended recipient you should not use, disclose, distribute or copy any of the content of it or of any attachment; you are requested to notify the sender immediately of your receipt of the email and then to delete it and any attachments from your system. RNIB endeavours to ensure that emails and any attachments generated by its staff are free from viruses or other contaminants. However, it cannot accept any responsibility for any such which are transmitted. We therefore recommend you scan all attachments. Please note that the statements and views expressed in this email and any attachments are those of the author and do not necessarily represent those of RNIB. RNIB Registered Charity Number: 226227 Website: http://www.rnib.org.uk

6 11

Dates again
by Steven Kuck 03 Jan '05

03 Jan '05

I see this topic has been discussed years ago, but I recently started running some MailMan lists and this problem came up almost as soon as I started running it. (Version 2.1.5) Users WILL NOT set their clocks to some nicely synchronized time. This is especially true since many of my subscribers are computer neophytes. When sorted by date, some replies come before the original posting. The worst offender is actually a highly competent computer user who claims to have a defective clock in his laptop that produces messages from the year 2080. (The truth of his claim is immaterial.) In an ideal world, these things would never happen. This is not an ideal world. There was a discussion about "not munging" the headers as a validation for objecting to altering the "Date" header. Considering the actions of "CookHeaders.py" and other files that variously alter the "Reply To" header, delete unwanted headers, and obviously alter the "Subject" line, these objections seem weak, if not ironic. The date set by the senders computer is not sacrosanct. While it may have some "meaning," it is of no "use." Also, if the date isn't set properly, it probably isn't even important to the sender. Since all of these messages are, in fact, being sent by my server I think it quite reasonable to change the "Date" to reflect the time that it was processed and changed by the server. I'm the one who has to answer questions about why the archive dates seem wrong and who is ultimately responsible for the smooth operation of the service. I would LIKE this to be an option that I could set. I do not have the time or inclination to write the code to make this a user option. However, since it something I wanted applied to all of my lists, I added the code to copy the "Date" field to "X-Original-Date" and put in the server's time as the "Date." Suddenly, my new archives are coherent. I don't have to worry about aberrant or obnoxious users. I only added six lines of code (and two imports) to "CookHeaders.py" to make this work. PLEASE tell me I wasted my time and there is a simple option I can set! Tell me that I don't have to port this code when I want to upgrade! I don't speak Python, and I know I imported more than necessary, but it seems to work. I'm including the code changes both to share what I found to be Very Useful and to have others sanity-check my code. As I said, I never wrote a line of Python before this. Steven Kuck PS I considered sending this message from the year 2080 as I've had to deal with, but I thought I'd give you a chance to implement this patch first. PPS No, I don't WANT there to be a "fuzzfactor" allowing "close enough" dates. Server Time Only. # SKuck Header additions to CookHeaders.py of Mailman 2.1.5 - Nov 18, 2004 import time from email.Utils import parsedate_tz, mktime_tz, formatdate # End SKuck Header additions ... msg['List-Id'] = listid_h # The above included as an insertion location reference. I think it'll work from anywhere in "def process" # SKuck added to pounce on bad email time stamps. originaldate = msg.get('date') receivedtime = formatdate(time.time()) del msg['date'] del msg['x-original-date'] msg['Date'] = receivedtime msg['X-Original-Date'] = originaldate # End SKuck added ...

13 26

Bug when canceling invites...
by Carson Gaspar 01 Jan '05

01 Jan '05

If the invited person uses the link included in an invite and tries to cancel the invitation themselves, this happens.... Bug in Mailman version 2.1.5 We're sorry, we hit a bug! If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! Traceback: Traceback (most recent call last): File "/Tools/SunOS_5.9_i86pc/mailman-2.1.5/scripts/driver", line 87, in run_main main() File "/Tools/SunOS_5.9_i86pc/mailman-2.1.5/Mailman/Cgi/confirm.py", line 114, in main subscription_cancel(mlist, doc, cookie) File "/Tools/SunOS_5.9_i86pc/mailman-2.1.5/Mailman/Cgi/confirm.py", line 312, in subscription_cancel userdesc = mlist.pend_confirm(cookie)[1] File "/Tools/SunOS_5.9_i86pc/mailman-2.1.5/Mailman/Pending.py", line 141, in pend_confirm assert self.Locked() AssertionError Python information: Variable Value sys.version 2.3.4 (#1, Oct 5 2004, 07:57:49) [C]

4 3

Excessive unsubscriptions
by Luke Hilton 31 Dec '04

31 Dec '04

Hi All, I am very new to Linux, but will tell you what I can. I am trying to diagnose a problem on a. Linux Redhat server Mailman version 2.1.4 Spamassassin Squirrelmail The particular mailing list has over 20,000 members. The list is being sent to on a on a monthly basis one way. A mass mail (80k - html) was sent out to the 20,000 members approximately 2 weeks ago. All seemed to go fine. I was alerted that the server performance had dropped dramatically so I checked the obvious and then bounced it. The following day I received approx. 3000 unsubscribe notices. This is highly irregular as in the past only a few unsubscribe notices come in per month. I checked these entries in the Membership list and they are still there, but the 'nomail' box is now checked and reason 'B' displayed. A colleague of mine restarted the server again yesterday and I have just received another huge amount of unsubscribe notices again. I followed the following faq yesterday in an attempt to diagnose. http://www.python.org/cgi-bin/faqw-mm.py?req=show <http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.014.htp> &file=faq03.014.htp 1. Permissions seemed fine 2. Cron daemon was running 3. Aliases are in /etc/aliases + did a 'newaliases' 4. I checked the mailman/locks and there are a number of locks from around the time the list was sent 5. I checked to see if the processes are still around for the above locks and they are Should I delete the locks? If so how do I do this safely? Has anyone heard of this type of problem happening before? I want to make sure there are no pending mailman tasks to complete and that if another restart occurs I won't get bombarded by another wad of unsubscribes. I have a copy of the membership list and was thinking I could create 3 new mailing lists and divide the 20000 people over the 4 lists. Is this worth it? Should mailman be able to send 20,000 mails easily? Any help with this would be fantastic. Luke

3 6

new feature request (was: Re: setting a list for no daily reminders?)
by Mark 31 Dec '04

31 Dec '04

Thanks to everyone who responded. Please forgive this crosspost to the developers group. Seeing that there is no way to do this without changing the code, and that many Mailman users are not Python programmers or do not have the permission to make such changes on the server they are using, I think it would be best if this was made an option that could be set through the web interface for each list. That way administrators could choose immediate notifications, daily summaries, or both. THANX!! :) On 11/20/04, Mark Sapiro put forth: >Mark wrote: > > > >I am running a list set to immediately send administrative requests > >(admin_immed_notify set to yes), but I am getting daily notices as > >well. I don't want to receive daily notices. The immediate notices > >are sufficient. Nor do I see the logic in filling my inbox with > >daily notices when I'm not around or haven't had a chance to process > >the immediate notices that are already sitting there. > > > >Is there any way to change this?? > >You could delete the checkdbs entry from crontab, but this would affect >all lists and also would have the side effect of never clearing stale >entries from hold_and_cmd_autoresponses[] (I don't think this is >serious because I don't think there is ever more than one entry per >user - stale entries get "reused"). > >The only other way and the only way to do it per list is to change the >code in checkdbs.

3 5

Maybe it's time to release 2.1.6
by Tokio Kikuchi 03 Dec '04

03 Dec '04

Hi Developers, Since I took charge of CVS committer this September, I belive we could fix number of bugs, merged a few new small-but-nice features, and the code became fairly stable. And, I write 'fixed in CVS' many times answering bug reports these days. Although I have some new features to be added in mind in a longer time scale, I think it is time to take the schedule of new release into consideration. I would like you the developers to download the current source from the CVS (Release_2_1-maint) and test on your testing/working sites before Barry can arrange the time schedule of releasing 2.1.6. Cheers, -- Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp http://weather.is.kochi-u.ac.jp/

10 16

Status of bug #974290 unknown encoding crashes qrunner?
by Stephen J. Turnbull 01 Dec '04

01 Dec '04

What is the status of these bugs? bug #974290 unknown encoding crashes qrunner bug #926034 crashes on encoding errors I seem to recall that Tokio Kikuchi or maybe Jim Tittsler had a fix, but there's nothing about it in the tracker, and I can't find it in my mailman-developers archive. There are a few posts with the words "unknown encoding" in them on mailman-users and mailman-developers, but no fixes. :-( I can probably get my host to install the codecs (I assume that would help), but this really shouldn't crash the runner. I'm seeing this under Mailman 2.1.5, on a fairly motley RedHat system (I think it was running 5.x when we started hosting our lists there, it's been upgraded piece-by-piece, often from source, since then). Of course it's all Chinese spam in GB2312, but it would be nice if it didn't fill the error log and the shunt queue, and simply evaporated instead.<wink> -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

2 4

admin_member_chunksize not available in GUI or config_list
by Mark Sapiro 23 Nov '04

23 Nov '04

I have submitted this at https://sourceforge.net/tracker/index.php?func=detail&aid=1072002&group_id=… -- Mark Sapiro <msapiro(a)value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 0

Re: Two problems upgrading from 2.1.4 to 2.1.5
by Greg Ward 21 Nov '04

21 Nov '04

[moving thread to mailman-developers, since I think I found a bug -- and sorry for the huge quote, but I think the change of audience requires it] On 21 November 2004, I said: > I'm trying to upgrade from Mailman 2.1.4 to 2.1.5 on a Debian "testing" > system, using "apt-get install mailman". The upgrade seems to be > falling down in two places at various times. First variation: > > """ > # apt-get install mailman > Reading Package Lists... Done > Building Dependency Tree... Done > mailman is already the newest version. > 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded. > 1 not fully installed or removed. > Need to get 0B of archives. > After unpacking 0B of additional disk space will be used. > Setting up mailman (2.1.5-3) ... > Looking for enabled languages (this may take some time) ... done. > Installing site language de ................................ done. > Installing site language en ............................................ done. > Upgrading from version 0x20103f0 to 0x20105f0 > getting rid of old source files > Updating mailing list: mailman > Updating the held requests database. > - updating old private mbox file > Your installation seems up-to-date, great! > - updating old public mbox file > Fixing language templates: mailman > > Updating mailing list: crew > Resetting 2 BYBOUNCEs disabled addrs with no bounce info > Traceback (most recent call last): > File "/usr/lib/mailman/bin/update", line 753, in ? > errors = main() > File "/usr/lib/mailman/bin/update", line 643, in main > errors = errors + dolist(listname) > File "/usr/lib/mailman/bin/update", line 218, in dolist > mlist.setDeliveryStatus(addr, ENABLED) > File "/var/lib/mailman/Mailman/OldStyleMemberships.py", line 338, in setDeliveryStatus > self.__assertIsMember(member) > File "/var/lib/mailman/Mailman/OldStyleMemberships.py", line 113, in __assertIsMember > raise Errors.NotAMemberError, member > Mailman.Errors.NotAMemberError: timehorse,timehorse(a)unforgettable.com > dpkg: error processing mailman (--configure): > subprocess post-installation script returned error exit status 1 > Errors were encountered while processing: > mailman > E: Sub-process /usr/bin/dpkg returned an error code (1) > """ > > When I saw this, I shrugged, figured I'd look in more detail later, and > just tried again. This time it's getting bogged down in the middle of > updating the pending.pck file: > > """ > # apt-get install mailman > Reading Package Lists... Done > Building Dependency Tree... Done > mailman is already the newest version. > 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded. > 1 not fully installed or removed. > Need to get 0B of archives. > After unpacking 0B of additional disk space will be used. > Setting up mailman (2.1.5-3) ... > Looking for enabled languages (this may take some time) ... done. > Installing site language de ................................ done. > Installing site language en ............................................ done. > Upgrading from version 0x20103f0 to 0x20105f0 > getting rid of old source files > Updating mailing list: mailman > [...] > Updating Usenet watermarks > - nothing to update here > Updating Mailman 2.1.4 pending.pck database > """ > > The [...] went by quite quickly. After printing the last line, 'update' > just sits there. Interrupting it gives a useful traceback: > > Traceback (most recent call last): > File "/usr/lib/mailman/bin/update", line 753, in ? > errors = main() > File "/usr/lib/mailman/bin/update", line 677, in main > update_pending() > File "/usr/lib/mailman/bin/update", line 572, in update_pending > mlist = MailList.MailList(listname) > File "/var/lib/mailman/Mailman/MailList.py", line 126, in __init__ > self.Lock() > File "/var/lib/mailman/Mailman/MailList.py", line 159, in Lock > self.__lock.lock(timeout) > File "/var/lib/mailman/Mailman/LockFile.py", line 312, in lock > self.__sleep() > File "/var/lib/mailman/Mailman/LockFile.py", line 496, in __sleep > time.sleep(interval) > KeyboardInterrupt > > Hmmmm... so it looks like it's trying to get the lock on a list. Not > sure which one, but here's a clue: OK, it looks like this is what happened: * the first failure (NotAMemberError) crashed update, and it did not clean up its locks * so when I ran update again, it hung trying to lock the list that it crashed on the last time through Looking at the loop of setDeliveryStatus() calls in dolist() (see around lines 215-220 in bin/update), it's pretty obvious how an exception from setDeliveryStatus() can cause havoc. One naive fix is to catch MemberError from setDeliveryStatus(): --- update 2004-11-01 11:22:53.000000000 +0100 +++ update.hacked 2004-11-21 20:08:21.000000000 +0100 @@ -51,6 +51,7 @@ from Mailman import MailList from Mailman import Message from Mailman import Pending +from Mailman import Errors from Mailman.LockFile import TimeOutError from Mailman.i18n import _ from Mailman.Queue.Switchboard import Switchboard @@ -215,7 +216,11 @@ print _( 'Resetting %(n)s BYBOUNCEs disabled addrs with no bounce info') for addr in noinfo.keys(): - mlist.setDeliveryStatus(addr, ENABLED) + try: + mlist.setDeliveryStatus(addr, ENABLED) + except Errors.MemberError, err: + print "ERROR setting delivery status" + print repr(err) # Update the held requests database print _("""Updating the held requests database.""") (patch relative to bin/update from a Debian mailman_2.1.5-3 installation). But I presume it would be cleaner to wrap a try/finally around most of dolist(). Anyways, with this patch in place, I am able to run update successfully -- ie. no hanging getting a lock. Greg -- Greg Ward <gward(a)python.net> http://www.gerg.ca/ Jesus Saves -- but Moses gets the rebound, he shoots, he SCORES!

1 0

Translation not working?
by Christiaan den Besten 16 Nov '04

16 Nov '04

Hi ! I am using a MailMan (mailman-2.1.5-6.src.rpm) list with the "Dutch" language. Unfortunately, one of the templates is not working 100%. The 'confirm subscription' message is displayed in English and not in Dutch ;( I have pinpointed the correct return value to be present in the translation file (see below). Is there anything I could check / change to debug this ? bye, Chris --- #: Mailman/Cgi/confirm.py:245 #, fuzzy msgid "" "Your confirmation is required in order to complete the\n" " subscription request to the mailing list %(listname)s. Your\n" " subscription settings are shown below; make any necessary changes and " "hit\n" " Subscribe to complete the confirmation process. Once you've\n" " confirmed your subscription request, you will be shown your account\n" " options page which you can use to further customize your membership\n" " options.\n" "\n" " Note: your password will be emailed to you once your subscription is\n" " confirmed. You can change it by visiting your personal options page.\n" "\n" " Or hit Cancel my subscription request if you no longer want " "to\n" " subscribe to this list." msgstr "" "Uw bevestiging is vereist om uw aanmeldingsverzoek voor de maillijst\n" " %(listname)s te voltooien. Uw lidmaatschapsinstellingen\n" " zijn hieronder weergegeven. Indien nodig kunt u deze gegevens wijzigen\n" " en op Aanmelden klikken om verder te gaan. Nadat u uw\n" " aanmeldingsverzoek heeft bevestigd komt u op uw lidmaatmaatschaps-\n" " instellingenpagina die u kunt gebruiken om uw lidmaatschap verder aan " "uw\n" " wensen aan te passen.\n" "\n" " Opmerking: uw wachtwoord zal naar u worden verstuurd via e-mial " "nadat\n" " uw lidmaatschap is bevestigd. U kunt het wachtwoord veranderen als u " "uw\n" " lidmaatschapsinstellingenpagina bezoekt.\n" "\n" " Of klik op Annuleren om dit aanmeldingsverzoek af te breken." ---

3 6