Mailman 3 July 2001 - 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

Allowing posts with certain topics/blocking all others
by Sarah K. Miller 16 Sep '02

16 Sep '02

I have a list that I'd like to enforce a set of headers on. In other words, each message subject must start with a certain word in order be posted. Has anybody found a way to do this? I know I can block messages with certain headers, but I want to block all messages and only allow those with the approved headers. If anybody has a great idea how to accomplish this, please pass it on ... -- Sarah

7 6

SMTPDirect?
by Alex Lau 06 Sep '02

06 Sep '02

Is this protocol able to send external email? Thanks Alex

2 1

Help?
by Eris 23 Feb '02

23 Feb '02

I need some assistance if possible i get the following errors after reading your trouble shooting i still have no idea what im doing wrong. # ./configure& [1] 21167 [root mailman-2.0.6]# loading cache ./config.cache checking for --with-python... no checking for python... /usr/bin/python checking Python interpreter... /usr/bin/python checking Python version... 1.5.2 checking for a BSD compatible install... /usr/bin/install -c checking whether make sets ${MAKE}... yes checking for true... /bin/true checking for --without-gcc... no checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking whether #! works in shell scripts... yes checking for --with-var-prefix... no checking for --with-username... mailman checking for mailman UID... 500 checking for --with-groupname... mailman checking for mailman GID... 500 checking permissions on /home/mailman... configure: error: ***** Installation directory /home/mailman is not configured properly! ***** Set-gid bit must be set for directory: /home/mailman ***** Permissions should be at least 02775: /home/mailman drwxr-xr-x 4 mailman mailman 1024 Feb 21 23:34 mailman [root mailman]# ls -al total 7 drwxr-xr-x 4 mailman mailman 1024 Feb 21 23:34 . drwxr-xr-x 15 root root 1024 Feb 21 23:20 .. -rw------- 1 mailman mailman 176 Feb 21 23:37 .bash_history -rwxr-xr-x 1 mailman mailman 434 Feb 21 23:20 .emacs -rw-r--r-- 1 mailman mailman 778 Feb 21 23:20 .ftphelp drwxr-xr-x 5 mailman mailman 1024 Feb 21 23:20 group drwxr-xr-x 4 mailman mailman 1024 Feb 21 23:20 user Anyone able to help?

2 1

RE: [Mailman-Users] list emails aren't being sent
by Enriko Groen 22 Jan '02

22 Jan '02

> -----Original Message----- > From: Moonlit Submit [mailto:moonlitsubmit@hotmail.com] > > Hello, > I need to know if there's a command for when > list's mail isn't being sent. > I do have shell access, but I need step by step instructions for this. The keyword is logfiles. Check the mailman /log directory and check the MTA (mailer) logfiles which are placed depending on your mailer and OS. Most probably /var/log/maillog or something similar... -- Enriko Groen, Hosting manager -------------------------------------------------------- netivity bv www.netivity.nl enriko.groen(a)netivity.nl 038 - 850 1000 van nagellstraat 4 8011 eb zwolle --------------------------------------------------------

4 3

thttpd?
by Justin Sheehy 01 Dec '01

01 Dec '01

Hello, A quick scan of the archives and the FAQ didn't turn anything up, so I thought I'd ask this here. Is anyone known to be using Mailman with thttpd? If so, are there any known gotchas or things to look out for? I can't think of a reason why it wouldn't work, but since the Mailman docs seem to assume Apache, I figured that it was worth asking before I went ahead and set up a listserver using thttpd/Mailman. Thanks. -Justin

2 7

[ANNOUNCE] Mailman 2.1 alpha 2
by barry＠digicool.com 14 Nov '01

14 Nov '01

This the official announcement for Mailman 2.1 alpha 2. Because it's an alpha, this announcement is only going out to the mailman-* mailing lists. I'll make two warnings: you probably should still not use this version for production systems (but TIA for any and all testing you do with it!), and I've already had a couple of bug fixes from early adopters. 2.1a2 should still be useful, but you might want to keep an eye on cvs and the mailman-checkins list for updates. I am only making the tarball available on SourceForge, so you'll need to go to http://sf.net/projects/mailman to grab it. You'll also need to upgrade to mimelib-0.4, so be sure to go to http://sf.net/projects/mimelib to grab and install that tarball first. To view the on-line documentation, see http://www.list.org/MM21/index.html or http://mailman.sf.net/MM21/index.html Below is an excerpt from the NEWS file for all the changes since 2.1alpha1. There are a bunch of new features coming down the pike, and I hope to have an alpha3 out soon. I'm also planning on doing much more stress testing of this version with real list traffic, and I'm hoping we'll start to get more languages integrated into cvs. Enjoy, -Barry -------------------- snip snip -------------------- 2.1 alpha 2 (11-Jul-2001) - Building o mimelib 0.4 is now required. Get it from http://mimelib.sf.net. If you've installed an earlier version of mimelib, you must upgrade. o /usr/local/mailman is now the default installation directory. Use configure's --prefix switch to change it back to the default (/home/mailman) or any other installation directory of your choice. - Security o Better definition of authentication domains. The following roles have been defined: user, list-admin, list-moderator, creator, site-admin. o There is now a separate role of "list moderator", which has access to the pending requests (admindb) page, but not the list configuration pages. o Subscription confirmations can now be performed via email or via URL. When a subscription is received, a unique (sha) confirm URL is generated in the confirmation message. Simply visiting this URL completes the subscription process. o In a similar manner, removal requests (via web or email command) no longer require the password. If the correct password is given, the removal is performed immediately. If no password is given, then a confirmation message is generated. - Internationalization o More I18N patches. The basic infrastructure should now be working correctly. Spanish templates and catalogs are included, and English, French, Hungarian, and Big5 templates are included. o Cascading specializations and internationalization of templates. Templates are now search for in the following order: list-specific location, domain-specific location, site-wide location, global defaults. Each search location is further qualified by the language being displayed. This means that you only need to change the templates that are different from the global defaults. Templates renamed: admlogin.txt => admlogin.html Templates added: private.html - Web UI o Redesigned the user options page. It now sits behind an authentication so user options cannot be viewed without the proper password. The other advantage is that the user's password need not be entered on the options page to unsubscribe or change option values. The login screen also provides for password mail-back, and unsubscription w/ confirmation. Other new features accessible from the user options page include: ability to change email address (with confirmation) both per-list and globally for all list on virtual domain; global membership password changing; global mail delivery disable/enable; ability to suppress password reminders both per-list and globally; logout button. [Note: the handle_opts cgi has gone away] o Color schemes for non-template based web pages can be defined via mm_cfg. o Redesign of the membership management page. The page is now split into three subcategories (Membership List, Mass Subscription, and Mass Removal). The Membership List subcategory now supports searching for member addresses by regular expression, and if necessary, it groups member addresses first alphabetically, and then by chunks. Mass Subscription and Mass Removal now support file upload, with one address per line. o Hyperlinks from the logos in the footers have been removed. The sponsors got too much "unsubscribe me!" spam from desperate user of Mailman at other sites. o New buttons on the digest admin page to send a digest immediately (if it's non-empty), to start a new digest volume with the next digest, and to select the interval with which to automatically start a new digest volume (yearly, monthly, quarterly, weekly, daily). DEFAULT_DIGEST_VOLUME_FREQUENCY is a new configuration variable, initially set to give a new digest volume monthly. o Through-the-web list creation and removal, using a separate site-wide authentication role called the "list creator and destroyer" or simply "list creator". If the configuration variable OWNERS_CAN_DELETE_THEIR_OWN_LISTS is set to 1 (by default, it's 0), then list admins can delete their own lists. This feature requires an adaptor for the particular MTA you're using. An adaptor for Postfix is included, as is a dumb adaptor that just emails mailman@yoursite with the necessary Sendmail style /etc/alias file changes. Some MTAs like Exim can be configured to automatically recognize new lists. The adaptor is selected via the MTA option in mm_cfg.py - Email UI o In email commands, "join" is a synonym for "subscribe". "remove" and "leave" are synonyms for "unsubscribe". New robot addresses are support to make subscribing and unsubscribing much easier: mylist-join@mysite mylist-leave@mysite o Confirmation messages have a shortened Subject: header, containing just the word "confirm" and the confirmation cookie. This should help for MUAs that like to wrap long Subject: lines, messing up confirmation. o Mailman now recognizes an Urgent: header, which, if it contains the list moderator or list administrator password, forces the message to be delivered immediately to all members (i.e. both regular and digest members). The message is also placed in the digest. If the password is incorrect, the message will be bounced back to the sender. - Performance o Refinements to the new qrunner subsystem which preserves FIFO order of messages. o The qrunner is no longer started from cron. It is started by a Un*x init-style script called bin/mailmanctl (see below). cron/qrunner has been removed. - Command line scripts o bin/mailmanctl script added, which is used to start, stop, and restart the qrunner daemon. o bin/qrunner script added which allows a single sub-qrunner to run once through its processing loop. o bin/change_pw script added (eases mass changing of list passwords). o bin/update grows a -f switch to force an update. o bin/newlang renamed to bin/addlang; bin/rmlang removed. o bin/mmsitepass has grown a -c option to set the list creator's password. The site-wide `create' web page is linked to from the admin overview page. o bin/newlist's -o option is removed. This script also grows a way of spelling the creation of a list in a specific virtual domain. o The `auto' script has been removed. o bin/dumpdb has grown -m/--marshal and -p/--pickle options. o bin/list_admins can be used to print the owners of a mailing list. o bin/genaliases regenerates from scratch the aliases and aliases.db file for the Postfix MTA. - Archiver o New archiver date clobbering option, which allows dates to only be clobber if they are outrageously out-of-date (default setting is 15 days on either side of received timestamp). New configuration variables: ARCHIVER_CLOBBER_DATE_POLICY ARCHIVER_ALLOWABLE_SANE_DATE_SKEW The archived copy of messages grows an X-List-Received-Date: header indicating the time the message was received by Mailman. o PRIVATE_ARCHIVE_URL configuration variable is removed (this can be calculated on the fly, and removing it actually makes site configuration easier). - Miscellaneous o Several new README's have been added. o Most syslog entries for the qrunner have been redirected to logs/error. o On SIGHUP, qrunner will re-open all its log files and restart all child processes. See "bin/mailmanctl restart". - Patches and bug fixes o SF patches and bug fixes applied: 420396, 424389, 227694, 426002, 401372 (partial), 401452. o Fixes in 2.0.5 ported forward: Fix a lock stagnation problem that can result when the user hits the `stop' button on their browser during a write operation that can take a long time (e.g. hitting the membership management admin page). o Fixes in 2.0.4 ported forward: Python 2.1 compatibility release. There were a few questionable constructs and uses of deprecated modules that caused annoying warnings when used with Python 2.1. This release quiets those warnings. o Fixes in 2.0.3 ported forward: Bug fix release. There was a small typo in 2.0.2 in ListAdmin.py for approving an already subscribed member (thanks Thomas!). Also, an update to the OpenWall security workaround (contrib/securelinux_fix.py) was included. Thanks to Marc Merlin.

12 20

Looping digest - mailman bug?
by Kaja P. Christiansen 10 Aug '01

10 Aug '01

Hi, On Wed, 20 Jun 2001 19:12:00 +0200, I wrote: > Last Monday, one of our mailing lists went mad and sent multiple copies > of the same digest to the list's digest users. > > [...] > > The traceback in the errors log shows: > > Jun 19 00:01:01 2001 (18618) Traceback (innermost last): > File "/usr/local/mailman203/Mailman/Handlers/HandlerAPI.py", line 82, in do_pipeline > func(mlist, msg, msgdata) > File "/usr/local/mailman203/Mailman/Handlers/Sendmail.py", line 86, in process > fp.write(msgtext) > IOError: [Errno 32] Broken pipe > > We run Mailman 2.0.3 with Postfix. I addressed this problem earlier > (March 26th), but there was no reply. Several of our lists suffered from Mailman's mail bombing and we turned the digest option off in hope it'll help. It did, for a while, until the same happened with a non-digest message being send over and over again (once per minute, by qrunner). We were able to locate where and how it happens, and to 'reproduce' the error (in laboratory conditions :-) both under mailman 2.0.3 and 2.0.6. The mail looping occurs when there is a MIME message with a single . (dot) in a line; Mailman sends it to sendmail 'as is'. But since sendmail/postfix interprets a line with single dot as the end of the message, it sends everything before the dot and exits with 'Broken pipe'. Mailman, however, still has the message in it's queue and sends it all over again... When I tried sending non-MIME message with single-dot-line in it to a Mailman list, there was no looping, but the message body after the single dot was missing. Until there is something better, I suggest adding to Sendmail.py a patch which perhaps is not pretty (it adds a space before the infamous dot), but it works: --- ./Mailman/Handlers/Sendmail.py.orig Fri Jul 27 13:40:31 2001 +++ ./Mailman/Handlers/Sendmail.py Fri Jul 27 14:11:46 2001 @@ -31,6 +31,7 @@ import string import os +import re import HandlerAPI from Mailman import mm_cfg @@ -80,6 +81,8 @@ msgtext = str(msg) # cycle through all chunks failedrecips = [] + bar = re.compile('\n\.') + msgtext = re.sub(bar, '\n .', msgtext, 0) for chunk in recipchunks: # TBD: SECURITY ALERT. This invokes the shell! fp = os.popen(cmd + chunk, 'w') Kaja

7 12

infinite loop on bounce from postmaster to list
by Rich Ramos 05 Aug '01

05 Aug '01

We had an ugly situation occur yesterday. Here's the summary: 1. 1+ Meg email sent to list with no size limit 2. An email user, who has a ccMail account that forwards his mail on to another account outside the company, has his outside mailbox hit his quota limit. (This user is also digested) 3. The MTA at the receiving end that detects the over quota and sends an email back to the list itself (see below for mail headers as to why this might happen). 4. Mailman sends this email back to everyone on the list including the digested mail user, whose MTA then rejects the email for the same reason as before. 5. Repeat steps 3 and 4 about every 8 minutes. This loop continues until the system comes to a halt from a full /tmp directory. On every iteration the mail message grew a little bigger because the last email gets copied on to the reject message. There are a few problems here, but I'm not sure which problem is the wrong case and which solution I should pursue. Problem #1. ccMail changes the headers when it processes the mail. Here's the normal headers from a post to mailman (I've stripped the Received lines): From: Rich Ramos <rich(a)chi.mti.com> To: test(a)chi.mti.com Message-ID: <563517.996585740(a)[144.86.11.157]> X-Mailer: Mulberry/2.1.0b3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [Test] test to show headers Sender: test-admin(a)chi.mti.com Errors-To: test-admin(a)chi.mti.com X-BeenThere: test(a)chi.mti.com X-Mailman-Version: 2.0.3 Precedence: bulk List-Help: <mailto:test-request@chi.mti.com?subject=help> List-Post: <mailto:test@chi.mti.com> List-Subscribe: <http://chi.mti.com/mailman/listinfo/test>, <mailto:test-request@chi.mti.com?subject=subscribe> List-Id: <test.chi.mti.com> List-Unsubscribe: <http://chi.mti.com/mailman/listinfo/test>, <mailto:test-request@chi.mti.com?subject=unsubscribe> List-Archive: <http://chi.mti.com/mailman/private/test/> Date: Tue, 31 Jul 2001 13:22:20 -0500 Here's the way the headers get changed by ccmail: Message-Id: <0107319966.AA996603967(a)ccmgate.mti.com> X-Mailer: ccMail Link to SMTP R8.30.00.7 Date: Tue, 31 Jul 2001 13:22:20 -0700 From: Rich Ramos <rich(a)chi.mti.com> To: <test(a)chi.mti.com> Subject: [Test] test to show headers MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="simple boundary" As you can tell it's quite a bit different. However I'm not totally clear that even with the changed headers, that the destination MTA should have sent the bounce message back to the list. With the From: and To: headers the way they are why didn't the MTA send the bouce back to the From: address? Problem #2: The message was being delivered to a digested user, however the bounces happened every few minutes. Why didn't the digest get sent once and then not again until the next interval for the digest? Doesn't mailman have some mechanism to catch looping posts to a list? -Rich

2 1

Looping problem...
by TJ Snider 01 Aug '01

01 Aug '01

I just ended up with a nasty loop... just when starting up a list. To reproduce: Use Mailman 2.0.5. Turn on the anonymous_list option, so mail seems to come from the list. Have someone on the list have a vacation notice setup. The notice loops... in this case up to 600 times, overnight, before I caught it. Is there any way of maintaining the anonymous_list feature without the looping? I've turned the anonymous_list feature off, but if it can't handle vacation notices, what's the use? TJ

2 1