Mailman 3 June 1998 - Mailman-Developers

file permissions
by Michael McLay 13 Jun '98

13 Jun '98

Either I screwed up when I followed the installation instructions or else the file ownership set by "make install" incorrectly set the group of the executables in $prefix/cgi-bin to that of the super user. In order for the scripts to work the group had to be manually set to "mailman". I accidentally created a copy of $prefix/data/pending_subscriptions.db with the wrong group ownership which caused the subcribe script to fail with an "Internal Server Error" The script failed because of a file access permission error. In order to find the problem I did some code reorganization. The $prefix/scripts/subscribe file was moved to $prefix/Mailman/subscribe.py and the attached file was put in place of the $prefix/scripts/subscribe file. This change should also reduce the script execution time slightly because the longer script will be compiled to a .pyc file. I would like to wrap all the other file in the $prefix/scripts/ in the same manner. Once this is done the common.c program can be modified to insert the PREFIX directory into the path rather than the MODULEDIR. This will eliminate the need for the paths module in each of the scripts and it would eliminate the need for the following lines in my new wrapper script: sys.path.remove('/usr/local/mailman/Mailman') sys.path.insert(0, '/usr/local/mailman') This generalized error wrapper would also eliminate some redundant error reporting code in admin. John, what do you think of removing the mm_ prefix from the module names? It's not really needed now that everything is pushed into the Mailman package. ----------------------- $prefix/scripts/subscribe --------------------- #! /usr/bin/env python # # Copyright (C) 1998 by the Free Software Foundation, Inc. # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License # as published by the Free Software Foundation; either version 2 # of the License, or (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. """Process listinfo form submission, ie subscriptions or roster requests.""" import sys from Mailman.subscribe import * try: sys.path.remove('/usr/local/mailman/Mailman') sys.path.insert(0, '/usr/local/mailman') from Mailman.subscribe import * except SystemExit: pass except: print "Content-type: text/html\n" print "<p><h3>We're sorry, we hit a bug!</h3>\n" print "If you would like to help us identify the problem, please " print "email a copy of this page to the webmaster for this site" print 'with a description of what happened. Thanks!' print "\n<PRE>" print sys.argv try: import traceback sys.stderr = sys.stdout traceback.print_exc() except: print "[failed to get traceback]" print "\n\n</PRE>"

3 7

File Locking
by John Viega 13 Jun '98

13 Jun '98

I'm going to attach what I hope is a portable module for file locking. I don't have time to integrate it with Mailman today, unfortunately, but if someone wants to try it out, or give suggestions for improvements to this code, let me know. John

1 0

smtplib buglet in 1.0b4
by Scott 12 Jun '98

12 Jun '98

the smtplib module in mailman 1.0b4 doesn't quite use strict rfc complient smtp syntax. Vmailer is strict about it, and other mailers may be as well. I changed smtplib.py so it sends "MAIL FROM: <address>" and "RCPT TO: <address>" instead of "MAIL FROM: address" and "RCPT TO: address". scott here's a patch: chronis 7:32pm $ diff -c /home/mm/Mailman/smtplib.py /home/scott/mailman-1.0b4/modules/smtplib.py *** /home/mm/Mailman/smtplib.py Thu Jun 11 19:30:06 1998 --- /home/scott/mailman-1.0b4/modules/smtplib.py Fri May 29 23:09:21 1998 *************** *** 64,77 **** if headers: hlines = string.split(headers, '\n') lines = string.split(text, '\n') ! self._sock.send('MAIL FROM: <%s>\r\n' % frm) self.getresp() if type(to) == types.StringType: ! self._sock.send('RCPT TO: <%s>\r\n' % to) self.getresp() else: for item in to: ! self._sock.send('RCPT TO: <%s>\r\n' % item) self.getresp() self._sock.send('DATA\r\n') self.getresp() --- 64,77 ---- if headers: hlines = string.split(headers, '\n') lines = string.split(text, '\n') ! self._sock.send('MAIL FROM: %s\r\n' % frm) self.getresp() if type(to) == types.StringType: ! self._sock.send('RCPT TO: %s\r\n' % to) self.getresp() else: for item in to: ! self._sock.send('RCPT TO: %s\r\n' % item) self.getresp() self._sock.send('DATA\r\n') self.getresp()

4 5

More mailman locking issues
by Ken Manheimer 12 Jun '98

12 Jun '98

Another issue with mailman locking - i think it's coarse grained, and needs to be refined. For example, this morning someone noticed that the umbrella listinfo page on python.org was hanging, because, it turns out, one of the lists was left in a locked state. (Not sure how that happened - it usually doesn't.) Well, the umbrella listinfo (and admin) pages open the lists only for the sake of determining which are public ones - no writing is actually required, so a lock isn't really required. It might be sufficient to offer a way to open a list "read-only", such that no locking is done. I think it would be better, however, to refine the locking system such that lists are not locked until they enter an operation that changes the list data in a way that will eventually need to be written. This would probably take a more effort than a "read-only" kluge, but may not be too bad. I guess this is one for the todo list. (Wish i had gobs of time to continue to hack on a these sorts of things - they're not very big or hard, but there is a bunch of them, and they need to be done right.) Ken

4 4

Re: [Mailman-Developers] Does bouncing by header regexps really work?
by Janne Sinkkonen 09 Jun '98

09 Jun '98

John Viega <viega(a)list.org> writes: > I won't have the chance to look until later this week, but I'm > wondering if it may be a case sensitivity problem? OK, this seems to help: --- maillist.py~ Thu Jun 4 23:12:28 1998 +++ maillist.py Tue Jun 9 19:39:45 1998 @@ -718,13 +718,13 @@ continue else: try: - h, e = re.split(":[ ]*", line) - all.append((h, e, line)) + h, e = re.split(":[ ]*", stripped) + all.append((h, e, stripped)) except ValueError: # Whoops - some bad data got by: self.LogMsg("config", "%s - " "bad bounce_matching_header line %s" - % (self.real_name, `line`)) + % (self.real_name, `stripped`)) return all @@ -748,7 +748,7 @@ and f[l] == ":" and string.lower(field) == string.lower(f[0:l])): # Non-continuation line - trim header name: - subjs.append(f[l+1:]) + subjs.append(f[l+2:]) elif not subjs: # Whoops - non-continuation that matches? subjs.append(f)

1 0

Does bouncing by header regexps really work?
by Janne Sinkkonen 09 Jun '98

09 Jun '98

I don't think so. Or do I have something wrong with these? > content-type: multipart > x-ms-attachment: .* > return-receipt-to: .* -- Janne

2 1

fyi
by John Viega 08 Jun '98

08 Jun '98

I just wanted to let everyone know that I'm not going to be as quick to respond as I normally try to be for the rest of the week. I'm just starting a new job, and I have to still set stuff up before I have outside access. So I'm only going to be reading mail once a day until probably the end of the week. Over the weekend I plan to catch up on integrating patches from this list and making the changes I promised a day or so ago. John

1 0

Re: [Mailman-Developers] '&' in an address
by Janne Sinkkonen 06 Jun '98

06 Jun '98

John Viega <viega(a)list.org> writes: > will make sure there's some sort of solution by b5. For now, I would > suggest you remove the address from the list. No problem here. If somebody has such a mail address, (s)he should be prepared to suffer. :) The admin removed it already, apparently it was easy because he managed to do it without any help. -- Janne

1 0

'&' in an address
by Janne Sinkkonen 06 Jun '98

06 Jun '98

I have never before seen an address with '&' in it, but now we have 'r&d.nylund(a)somewhere.com' on one of our lists. It is a problem, since the error log shows the followig when a message is posted to the list: Jun 06 07:55:39 1998 post: Traceback (innermost last): post: File "/home/mailman/scripts/mailowner", line 43, in ? post: if not current_list.bounce_processing or not current_list.ScanMessage(msg): post: File "/home/mailman/Mailman/mm_bouncer.py", line 407, in ScanMessage post: self.RegisterBounce(who, msg) post: File "/home/mailman/Mailman/mm_bouncer.py", line 83, in RegisterBounce post: self.LogMsg("bounce", report + "first") post: File "/home/mailman/Mailman/maillist.py", line 570, in LogMsg post: logf.write("%s\n" % (msg % args)) post: TypeError : not enough arguments for format string I have 1.0b4, but the subscription was made while we were running an earlier version. It's possible that the address found its way to the list through the admin's mass subscription. Either mailman shouldn't allow such addresses to be subscribed, or then the post script needs fixing. -- Janne

2 1

Lock patches?
by Steve Spicklemire 06 Jun '98

06 Jun '98

Hi There, I'm using mailman on NeXTStep. One of the problems I ran into was the non-functionality of lock file support on NeXTStep. Soooo.... I cooked up a (more or less) satisfactory replacement. Would anyone else on the list be interested in the canges? Basically I create a normal file as the 'lock'. I create it with flags that require mailman to have exclusive write access to it. If another mailman process is already using the file, the create fails. There is an optional 'timeout' period, so that a hung/dead process won't cut out all other mailman processes. Are there other platforms where file locking is a problem? -steve

2 1