From Dan@feld.cvut.cz Wed Jul 1 13:40:13 1998 From: Dan@feld.cvut.cz (Dan Ohnesorg, admin on power) Date: Wed, 1 Jul 1998 14:40:13 +0200 Subject: [Mailman-Developers] Some patch for mailman Message-ID: Hi everybody, I am plaing with mailman some time (John probaly remebers me) and now I see, that www.list.org is back online. So what I have, I would suggest You patch to verbose funcionality of mailman. All sugestion to my solution are welcome. What it solves, first part of patch to remove irriting headers from messages. I dont like to send messages like RCPT and so. Second uses DSN to send mails. This disables (when enabled) messages like warning, message is not delivered for 4 hours and so. Then comes some removing of winmail.dat binary attachments. I am working on removing all unwanted parts (html, rtf) and translating national characters into ascii, but is not complete yet. Then comes administrativ via filter, but it not works, it worked on mailman 1.0, but I cannot bring it running on b4, You will see, it is probably only a little bug, at least the filter shields list from administrative messages. So it is all for today, I am interested how You will find this patch, please send any comments to my. cheers dan diff -ru mailman-1.0b4/modules/mm_defaults.py mailman-1.0b4.new/modules/mm_defaults.py --- mailman-1.0b4/modules/mm_defaults.py Fri Jun 26 12:41:28 1998 +++ mailman-1.0b4.new/modules/mm_defaults.py Fri Jun 26 18:43:28 1998 @@ -202,3 +202,11 @@ # The Mailman version, also set by configure VERSION = '1.0b4' + +# Remove Microsoft binary attachments +REMOVE_WINMAIL = 1 +WINMAIL_FILTER_START = 'begin 600 WINMAIL\.DAT' +WINMAIL_FILTER_STOP = 'end' + +# Headers which are not useful +FILTER_HEADERS = ['^X-Confirm-Reading-To:','^X-pmrqc:','X-PMFLAGS:','^Return-receipt-to:'] Only in mailman-1.0b4/modules: mm_defaults.py.in diff -ru mailman-1.0b4/modules/mm_deliver.py mailman-1.0b4.new/modules/mm_deliver.py --- mailman-1.0b4/modules/mm_deliver.py Wed Jun 3 15:12:53 1998 +++ mailman-1.0b4.new/modules/mm_deliver.py Fri Jun 26 18:32:35 1998 @@ -135,6 +135,12 @@ msg.headers.append('To: %s\n' % self.GetListEmail()) else: tempfile.template = tmpfile_prefix + 'mailman.' +# Now remove unwanted headers from message + for pat in mm_defaults.FILTER_HEADERS: + try: + del msg[pat] + except: + pass if self.reply_goes_to_list: del msg['reply-to'] msg.headers.append('Reply-To: %s\n' % self.GetListEmail()) diff -ru mailman-1.0b4/modules/mm_message.py mailman-1.0b4.new/modules/mm_message.py --- mailman-1.0b4/modules/mm_message.py Tue Jun 2 04:47:11 1998 +++ mailman-1.0b4.new/modules/mm_message.py Fri Jun 26 18:01:47 1998 @@ -21,7 +21,7 @@ import sys -import rfc822, string, time +import rfc822, string, time, mm_defaults, regex # Utility functions 2 of these classes use: @@ -134,6 +134,24 @@ if (string.lower(self.headers[i][:len(name)+1]) == string.lower(name) + ':'): self.headers[i] = '%s: %s' % (name, value) + + def RemoveWinmail(self): + pattern_start = regex.compile(mm_defaults.WINMAIL_FILTER_START) + pattern_stop = regex.compile(mm_defaults.WINMAIL_FILTER_STOP) + occured = 0 + mybody=[] + mybody=string.split(self.body,'\n'); + for line in mybody[:]: + if occured == 1: + if pattern_stop.match(line) > 0: + occured = 0 + mybody.remove(line) + elif pattern_start.match(line) > 0: + occured = 1 + mybody.remove(line) + self.body=string.join(mybody,'\n') + + # XXX Eventually (1.5.1?) Python rfc822.Message() will have its own # __delitem__. diff -ru mailman-1.0b4/modules/smtplib.py mailman-1.0b4.new/modules/smtplib.py --- mailman-1.0b4/modules/smtplib.py Sat May 30 05:09:21 1998 +++ mailman-1.0b4.new/modules/smtplib.py Wed Jul 1 14:27:23 1998 @@ -20,6 +20,9 @@ # A lot of functionality was borrowed directly from ftplib... # John Viega (viega@list.org) +# Hack to use DSN, probably not the best way, but works fine +# But I have no not DSN aware server to check it without DSN + # >>> from smtplib import * # >>> s = SmtpConnection('list.org') # >>> s.helo('adder.cs.virginia.edu') @@ -27,7 +30,7 @@ # >>> s.quit() from socket import * -import string, types +import string, types, regex SMTP_PORT = 25 @@ -38,6 +41,8 @@ error_temp = 'smtplib.error_temp' # 4xx errors error_perm = 'smtplib.error_perm' # 5xx errors error_proto = 'smtplib.error_proto' # response does not begin with [1-5] +error_no_DSN = 'There is no DSN support' +DSN_support = 1 class SmtpConnection: def __init__(self, host=''): @@ -52,8 +57,15 @@ self.getresp() def helo(self, host): - self._sock.send('HELO %s\r\n' % host) - self.getresp() + self._sock.send('EHLO %s\r\n' % host) + try: + vysl = self.getresp() + except error_perm: + self._sock.send('HELO %s\r\n' % host) + self.getresp() + self.DSN_support=0 + if regex.match('.*DSN.*',vysl) == -1: + self.DSN_support=0 def quit(self): self._sock.send('QUIT\r\n') @@ -66,12 +78,16 @@ lines = string.split(text, '\n') self._sock.send('MAIL FROM: %s\r\n' % frm) self.getresp() + if DSN_support: + format = 'RCPT TO: %s NOTIFY=failure\r\n' + else: + format = 'RCPT TO: %s\r\n' if type(to) == types.StringType: - self._sock.send('RCPT TO: %s\r\n' % to) + self._sock.send(format % to) self.getresp() else: for item in to: - self._sock.send('RCPT TO: %s\r\n' % item) + self._sock.send(format % item) self.getresp() self._sock.send('DATA\r\n') self.getresp() diff -ru mailman-1.0b4/scripts/post mailman-1.0b4.new/scripts/post --- mailman-1.0b4/scripts/post Sun May 31 06:48:09 1998 +++ mailman-1.0b4.new/scripts/post Fri Jun 26 18:06:57 1998 @@ -31,7 +31,7 @@ import sys import paths -import maillist, mm_message, mm_err, mm_cfg, mm_utils +import maillist, mm_message, mm_err, mm_cfg, mm_utils, string, mm_defaults try: sys.stderr = mm_utils.StampedLogger("error", label = 'post', @@ -42,6 +42,18 @@ # Only let one program run at once per list. # TODO: This can fail, and should send back an error message when it does. +commands = { + 'subscribe' : '', + 'unsubscribe' : '', + 'who' : '', + 'info' : '', + 'lists' : '', + 'help' : '', + 'set' : '', + 'options' : '', + 'password' : '', + } + current_list = maillist.MailList(sys.argv[1]) if len(sys.argv) > 2: current_list.tmp_prevent_gate = 1 @@ -60,10 +72,41 @@ else: text = sys.stdin.read() msg = mm_message.IncomingMessage(text) + if mm_defaults.REMOVE_WINMAIL: msg.RemoveWinmail() + bad_dest = 0 + subject = msg.getheader("subject") + if subject: + subject = string.strip(subject) + if commands.has_key(string.split(subject)[0]): + bad_dest = 1 + lines = string.split(msg.body, '\n') + if len(lines) >= 10: + hopcnt = range(10) + else: + hopcnt = range(len(lines)) + for i in hopcnt: + try: + string.strip(lines[i]) + except: + pass + if not lines[i]: + continue + args = string.split(lines[i]) + if len(args)>0: + cmd = string.lower(args[0]) + if commands.has_key(cmd): + bad_dest = 1 - try: + if bad_dest: + try: + current_list.ParseMailCommands() + finally: +# current_list.Unlock() + pass + else: + try: current_list.Post(msg) - except mm_err.MMNeedApproval, err_msg: + except mm_err.MMNeedApproval, err_msg: if (current_list.dont_respond_to_post_requests or err_msg == mm_err.MODERATED_LIST_MSG or err_msg == mm_err.IMPLICIT_DEST_MSG ________________________________________ DDDDDD DD DD Dan Ohnesorg, supervisor on POWER DD OOOO Dan@feld.cvut.cz DD OODDOO Dep. of Power Engineering DDDDDD OO CVUT FEL Prague, Bohemia OO OO work: +420 2 24352785;+420 2 24972109 OOOO home: +420 311 679679;+420 311 679311 ________________________________________ Pocitac se od televizniho divaka lisi tim, ze ma vlastni program. From gorgo@caesar.elte.hu Thu Jul 2 12:47:18 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Thu, 2 Jul 1998 13:47:18 +0200 (METDST) Subject: [Mailman-Developers] mailpasswds Message-ID: Hello! I have problems with mailpasswds... first it did not work because of this line: url = list.GetOptionsURL(user) I changed it to: url = list.GetAbsoluteOptionsURL(user) Now it starts (the text is a bit misplaced in the mails it sends), but forks too many times (I have two lists, 500 and 120 subscribers): Traceback (innermost last): File "/var/lib/mailman/cron/mailpasswds", line 114, in ? main() File "/var/lib/mailman/cron/mailpasswds", line 111, in main MailAllPasswords(list, users) File "/var/lib/mailman/cron/mailpasswds", line 78, in MailAllPasswords list.SendTextToUser(subject = subj, File "/usr/lib/mailman/Mailman/mm_deliver.py", line 105, in SendTextToUser mm_utils.SendTextToUser(subject, text, recipient, sender, File "/usr/lib/mailman/Mailman/mm_utils.py", line 145, in SendTextToUser DeliverToUser(msg, recipient, add_headers=add_headers) File "/usr/lib/mailman/Mailman/mm_utils.py", line 158, in DeliverToUser if os.fork(): os.error: (11, 'Resource temporarily unavailable') There should be a better way to handle these mails... either to have a better mailing algorithm, or to handle this error, wait for a minute, then continue. Greg -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From klm@python.org Thu Jul 2 22:07:36 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 2 Jul 1998 17:07:36 -0400 (EDT) Subject: [Mailman-Developers] mailpasswds In-Reply-To: References: Message-ID: <13723.62736.17291.209644@glyph.cnri.reston.va.us> --UfXfOrm0J+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gergely Madarasz writes: > I have problems with mailpasswds... first it did not work because of this > line: > url = list.GetOptionsURL(user) > I changed it to: > url = list.GetAbsoluteOptionsURL(user) > Now it starts (the text is a bit misplaced in the mails it sends), but > forks too many times (I have two lists, 500 and 120 subscribers): > [...] > There should be a better way to handle these mails... either to have a > better mailing algorithm, or to handle this error, wait for a minute, then > continue. You don't say which version you're running, but we ran into the same problem here at python.org (yesterday, when the passwords went out), and i've attacked the problem on two fronts in the current code. I'll describe what i did for the first one, if you want to try to reproduce it in your own code, and include a new version of cron/mailpasswds for 1.0b4 for the second. One fix is to change the "os.forks()" in the scripts/deliver script to use the following 'forker()' routine, which recognizes errno.EAGAIN, and retries to fork a specified number of times. (You have to have settings in the module for TRIES and REFRACT - i use 5 and 15, respectively.) TRIES = 5 REFRACT = 15 def forker(tries=TRIES, refract=REFRACT): """Fork, retrying on EGAIN errors with refract secs pause between tries. Returns value of os.fork(), or raises the exception for: (1) non-EAGAIN exception, or (2) EGAIN exception encountered more than tries times.""" got = 0 for i in range(tries): # Loop until we successfully fork or the number tries is exceeded. try: got = os.fork() break except os.error, val: import errno, sys, time if val[0] == errno.EAGAIN: # Resource temporarily unavailable. time.sleep(refract) else: # No go - reraise original exception, same stack frame and all. raise val, None, sys.exc_info()[2] return got Another solution is to have the mailpasswds script take some time to do an os.wait() every several users - i'm attaching a version of cron/mailpasswds for 1.0b4 that does this. --UfXfOrm0J+ Content-Type: text/plain Content-Description: 1.0b4 cron/mailpasswds which periodically waits for forked processes Content-Disposition: inline; filename="mailpasswds" Content-Transfer-Encoding: 7bit #! /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. """Send password reminders for all lists to all users. We accumulate users and their passwords, and use the last list to send a single message to each user with their complete collection of passwords, rather than sending a single message for each password.""" # This puppy should probably do lots of logging. import sys, os, string, time, errno import paths import maillist, mm_cfg, mm_message, mm_utils # Give time for the delivery process-forks to clear every so often, to # avoid saturation of the process table. Set zero or negative for no # pauses. PAUSE_FREQUENCY = 20 USERPASSWORDSTEXT = """ This is a reminder, sent out once a month, about your %s mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. Passwords for %s: %s %s You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, %s-request@%s) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@%s. Thanks! """ def MailAllPasswords(list, users): """Send each user their complete list of passwords. The list can be any random one - it is only used for the message delivery mechanism.""" subj = '%s maillist memberships reminder\n' % list.host_name count = PAUSE_FREQUENCY for user, data in users.items(): table = [] for l, p, u in data: if len(l) > 9: table.append("%s\n %-10s\n%s\n" % (l, p, u)) else: table.append("%-10s %-10s\n%s\n" % (l, p, u)) header = ("%-10s %-10s\n%-10s %-10s" % ("List", "Password // URL", "----", "--------")) text = USERPASSWORDSTEXT % (list.host_name, user, header, string.join(table, "\n"), l, list.host_name, list.host_name) list.SendTextToUser(subject = subj, recipient = user, text = text, sender = mm_cfg.MAILMAN_OWNER, add_headers = ["X-No-Archive: yes"], raw=1) count = count - 1 if count == 0: # The pause that refreshes. waitall() count = PAUSE_FREQUENCY def main(): """Consolidate all the list/url/password info for each user, so we send the user a single message with the info for all their lists on this site.""" list = None users = {} # user: (listname, password, url) for name in mm_utils.list_names(): list = maillist.MailList(name) list_name = list.real_name reminders_to_admins = list.reminders_to_admins for user, password in list.passwords.items(): url = list.GetAbsoluteOptionsURL(user) if reminders_to_admins: recipient = "%s-admin@%s" % tuple(string.split(user, '@')) else: recipient = user if users.has_key(recipient): users[recipient].append(list_name, password, url) else: users[recipient] = [(list_name, password, url)] # Unlocking each list after identifying passwords, but before having # the consolidated list, means that there is a window for discrepancy # between the reported and actual password. Big deal - if the user # changed the password in the meanwhile, they'll realize it, and it's # not worth the extra deadlock risk. list.Unlock() if list: MailAllPasswords(list, users) def waitall(): """Return only when there are no forked subprocesses running.""" try: while 1: os.wait() except os.error, val: if val[0] == errno.ECHILD: # errno.ECHILD: "No child processes" return else: raise val, None, sys.exc_info()[2] if __name__ == "__main__": main() --UfXfOrm0J+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I've done a little testing of both these approaches, but since the problem exists at the resource limit, and entails sending out messages to lots of people, i'm limited in the testing i could do. Caveat emptor! (And "everyone scrutinize" - the more eyes the better.) Ken Manheimer klm@python.org 703 620-8990 x268 (orporation for National Research |nitiatives # If you appreciate Python, consider joining the PSA! # # . # --UfXfOrm0J+-- From gorgo@caesar.elte.hu Sun Jul 5 13:48:12 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Sun, 5 Jul 1998 14:48:12 +0200 (METDST) Subject: [Mailman-Developers] mailpasswds In-Reply-To: <13723.62736.17291.209644@glyph.cnri.reston.va.us> Message-ID: On Thu, 2 Jul 1998, Ken Manheimer wrote: > You don't say which version you're running, but we ran into the same 1.0b4 > One fix is to change the "os.forks()" in the scripts/deliver script to > use the following 'forker()' routine, which recognizes errno.EAGAIN, and > retries to fork a specified number of times. (You have to have settings > in the module for TRIES and REFRACT - i use 5 and 15, respectively.) This seems the better solution, since it is more generic. Mailpasswds works now with the other solution, but convert_list and other mass-subscriptions dont. I think this should be included in the next release. > Another solution is to have the mailpasswds script take some time to > do an os.wait() every several users - i'm attaching a version of > cron/mailpasswds for 1.0b4 that does this. As I said, this just fixes mailpasswds, not the others. Thanks, Greg -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Tue Jul 7 20:15:04 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 7 Jul 1998 15:15:04 -0400 (EDT) Subject: [Mailman-Developers] Re: [Mailman-Users] Multilingual support in mailman? References: Message-ID: <13730.29624.78637.79684@anthem.cnri.reston.va.us> >>>>> "GM" == Gergely Madarasz writes: GM> I'd like to see something like that too... for a Hungarian GM> translation :) Actually, my architecture should be expanded a bit to make it work for multiple languages. Currently, there's a function called maketext() in the Utils module that takes a relative filename and a dictionary. The file is pulled out of the templates directory and contains %(key)s for interpolation of the dict. What we'd probably want to add are subdirs inside of templates for the various languages. Then each list would have to have a language option which would get passed to Utils.maketext() so that it could select the appropriate file to use (e.g. templates/en/cronpass.txt would the be English text, templates/hu/cronpass.txt would the be Hungarian, etc.). -Barry From Dan.Ohnesorg@feld.cvut.cz Tue Jul 7 22:43:25 1998 From: Dan.Ohnesorg@feld.cvut.cz (Dan Ohnesorg, admin of POWER) Date: Tue, 7 Jul 1998 23:43:25 +0200 Subject: [Mailman-Developers] Re: [Mailman-Users] Multilingual support in mailman? In-Reply-To: <13730.29624.78637.79684@anthem.cnri.reston.va.us> Message-ID: <17789354532@power.feld.cvut.cz> On 7 Jul 98, at 15:15, Barry A. Warsaw wrote: > Actually, my architecture should be expanded a bit to make it work for > multiple languages. Currently, there's a function called maketext() > in the Utils module that takes a relative filename and a dictionary. > The file is pulled out of the templates directory and contains %(key)s > for interpolation of the dict. > > What we'd probably want to add are subdirs inside of templates for the > various languages. Then each list would have to have a language > option which would get passed to Utils.maketext() so that it could > select the appropriate file to use (e.g. templates/en/cronpass.txt > would the be English text, templates/hu/cronpass.txt would the be > Hungarian, etc.). Very interesting, I will made czech translations. Some sugestion, mailman should select, in which language to respon from top domain name in e-mail. FE ...cz = czech, com = english and so on. cheers dan P.S. Why is there no respon to my patch???? Is so bad??? I think it mades interesting thinks....... ________________________________________ DDDDDD DD DD Dan Ohnesorg, supervisor on POWER DD OOOO Dan@feld.cvut.cz DD OODDOO Dep. of Power Engineering DDDDDD OO CTU FEL Prague, Bohemia OO OO work: +420 2 24352785;+420 2 24972109 OOOO home: +420 311 679679;+420 311 679311 ________________________________________ Kdyz jdes do sebe, nezastavuj pred kazdou hospodou. From viega@list.org Tue Jul 7 22:48:32 1998 From: viega@list.org (John Viega) Date: Tue, 7 Jul 1998 14:48:32 -0700 Subject: [Mailman-Developers] Re: [Mailman-Users] Multilingual support in mailman? In-Reply-To: <17789354532@power.feld.cvut.cz>; from Dan Ohnesorg, admin of POWER on Tue, Jul 07, 1998 at 11:43:25PM +0200 References: <13730.29624.78637.79684@anthem.cnri.reston.va.us> <17789354532@power.feld.cvut.cz> Message-ID: <19980707144832.B30797@list.org> On Tue, Jul 07, 1998 at 11:43:25PM +0200, Dan Ohnesorg, admin of POWER wrote: > > P.S. Why is there no respon to my patch???? Is so bad??? I > think it mades interesting thinks....... Personally, I have been working on a grant proposal for the past couple of weeks, and haven't had any time for outside activities. However, I'll look at it soon. John From gorgo@caesar.elte.hu Wed Jul 8 16:53:49 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Wed, 8 Jul 1998 17:53:49 +0200 (METDST) Subject: [Mailman-Developers] default digest mode Message-ID: Hello! It seems that setting default digest mode to plain has no effect at all... I could not find anything related to this in ApprovedAddMember, and i guess, it should be there... is this known ? -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From gorgo@caesar.elte.hu Wed Jul 8 18:09:27 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Wed, 8 Jul 1998 19:09:27 +0200 (METDST) Subject: [Mailman-Developers] default digest mode In-Reply-To: Message-ID: On Wed, 8 Jul 1998, Gergely Madarasz wrote: > It seems that setting default digest mode to plain has no effect at all... > I could not find anything related to this in ApprovedAddMember, and i > guess, it should be there... is this known ? Well... replying to myself is fun ;) I tried myself a bit with python (never used it before :)), and found a solution: I need a line self.SetUserOption(name,mm_cfg.DisableMime,1-self.mime_is_default_digest) right after the self.digest_members.append(name) line in ApprovedAddMember :) Greg -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From gorgo@caesar.elte.hu Thu Jul 9 19:46:46 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Thu, 9 Jul 1998 20:46:46 +0200 (METDST) Subject: [Mailman-Developers] error handling Message-ID: Hello! There is a bug in 1.0b4... if someone tries to subscribe while he is already subscribed, he does not get an explanation message, but an error message from sendmail stating "Unknown mailer error". MMAlreadyAMember should be handled here Greg -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Thu Jul 9 20:06:31 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 9 Jul 1998 15:06:31 -0400 (EDT) Subject: [Mailman-Developers] error handling References: Message-ID: <13733.5303.486168.936963@anthem.cnri.reston.va.us> >>>>> "GM" == Gergely Madarasz writes: GM> There is a bug in 1.0b4... if someone tries to subscribe while GM> he is already subscribed, he does not get an explanation GM> message, but an error message from sendmail stating "Unknown GM> mailer error". MMAlreadyAMember should be handled here I think Ken discovered this bug too, but I'm not sure it's been fixed in our current working copy. It definitely needs to be though. -Barry From klm@python.org Thu Jul 9 20:06:41 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 9 Jul 1998 15:06:41 -0400 (EDT) Subject: [Mailman-Developers] error handling In-Reply-To: Message-ID: On Thu, 9 Jul 1998, Gergely Madarasz wrote: > There is a bug in 1.0b4... if someone tries to subscribe while he is > already subscribed, he does not get an explanation message, but an error > message from sendmail stating "Unknown mailer error". MMAlreadyAMember > should be handled here This is a known bug, and it will be fixed in the next release. (I say this with confidence, though i haven't gotten time to investigate it yet - i actually plan to do so in the next couple of days.) I'll try to package a 1.0b4 fix, in addition to the doing the work on our internal development copy. ken manheimer klm@python.org From janne@avocado.pc.helsinki.fi Sat Jul 11 00:05:53 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 11 Jul 1998 02:05:53 +0300 Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem Message-ID: There exists a problem with MIME digests of b4 and some MTAs. Something in some digests makes the receiving end to think that it has received the whole message, while the sending MTA (mine was sendmail 8.8.5, now 8.9.1) thinks it failed and leaves the message to the spool. The message needs to be removed manually, for otherwise the poor subscriber will get a copy of it every time the mail queue is run, indefinitely. Does anybody know a remedy? I'm leaving for a holiday soon, and wouldn't like to write a script to be able to delete digests through my mobile phone... A maybe-related problem is that some messages are left to the mail spool even if they are expired. Apparently his has only happened with mailman, not with majordomo. (I just deleted a few thousands, the oldest dated May 1998.) Sounds like a sendmail problem, but I don't understand how it's related to mailman. -- Janne From viega@list.org Sat Jul 11 00:06:19 1998 From: viega@list.org (John Viega) Date: Fri, 10 Jul 1998 16:06:19 -0700 Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: ; from Janne Sinkkonen on Sat, Jul 11, 1998 at 02:05:53AM +0300 References: Message-ID: <19980710160619.A32600@list.org> Odd. I can't think of anything I know of that would give that sort of behavior. Can you look at one of these digests and see if there is anything suspect about them?? John On Sat, Jul 11, 1998 at 02:05:53AM +0300, Janne Sinkkonen wrote: > > There exists a problem with MIME digests of b4 and some > MTAs. Something in some digests makes the receiving end to think that > it has received the whole message, while the sending MTA (mine was > sendmail 8.8.5, now 8.9.1) thinks it failed and leaves the message to > the spool. The message needs to be removed manually, for otherwise the > poor subscriber will get a copy of it every time the mail queue is > run, indefinitely. > > Does anybody know a remedy? I'm leaving for a holiday soon, and > wouldn't like to write a script to be able to delete digests through > my mobile phone... > > A maybe-related problem is that some messages are left to the mail > spool even if they are expired. Apparently his has only happened with > mailman, not with majordomo. (I just deleted a few thousands, the > oldest dated May 1998.) Sounds like a sendmail problem, but I don't > understand how it's related to mailman. > > -- > Janne > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers From gorgo@caesar.elte.hu Sat Jul 11 00:25:46 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Sat, 11 Jul 1998 01:25:46 +0200 (METDST) Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: Message-ID: On 11 Jul 1998, Janne Sinkkonen wrote: > > There exists a problem with MIME digests of b4 and some > MTAs. Something in some digests makes the receiving end to think that > it has received the whole message, while the sending MTA (mine was > sendmail 8.8.5, now 8.9.1) thinks it failed and leaves the message to > the spool. The message needs to be removed manually, for otherwise the > poor subscriber will get a copy of it every time the mail queue is > run, indefinitely. This is a bug in sendmail, it segfaults on 8bitmime digests when sending them to hosts which don't support 8bitmime. I already wrote about this to the list a couple of weeks ago. Btw i thought 8.9.1 already has it fixed. Greg -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From klm@python.org Sat Jul 11 00:32:29 1998 From: klm@python.org (Ken Manheimer) Date: Fri, 10 Jul 1998 19:32:29 -0400 (EDT) Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: Message-ID: On Sat, 11 Jul 1998, Gergely Madarasz wrote: > On 11 Jul 1998, Janne Sinkkonen wrote: > > There exists a problem with MIME digests of b4 and some > > MTAs. Something in some digests makes the receiving end to think that > > it has received the whole message, while the sending MTA (mine was > > sendmail 8.8.5, now 8.9.1) thinks it failed and leaves the message to > > the spool. The message needs to be removed manually, for otherwise the > > poor subscriber will get a copy of it every time the mail queue is > > run, indefinitely. > > This is a bug in sendmail, it segfaults on 8bitmime digests when sending > them to hosts which don't support 8bitmime. I already wrote about this to > the list a couple of weeks ago. Btw i thought 8.9.1 already has it fixed. I also suspect that the sendmail problem is causing this particular behavior - check your mqeue for sendmail core dumps to confirm. I'm running sendmail 8.9.0 on python.org as of recently, and had to apply the patch that gergely sent me (thanks again, gergely) to get around the problem. I'm posting it here, for anyone that's interested and for the maillist archive. I think i'll include it and a note about it in the mailman distribution. Of course, this patch doesn't help the recipient sites running sendmail 8.8.x and 8.9.x (for some x'es). Question is, does anyone think we should we be constraining the digester to 7-bit mime messages - presumably stripping the 8th bit from messages that have it - just for the sake of a current bug in the most prominent MTA? I'd be loathe to do that, thinking that the bug should be exposed and get fixed. Ken *** collect.c.orig Wed May 20 02:36:05 1998 --- collect.c Thu May 28 13:29:09 1998 *************** *** 353,360 **** if (*--bp != '\n' || *--bp != '\r') bp++; *bp = '\0'; ! if (bitset(H_EOH, chompheader(buf, FALSE, hdrp, e))) ! mstate = MS_BODY; break; case MS_BODY: --- 353,364 ---- if (*--bp != '\n' || *--bp != '\r') bp++; *bp = '\0'; ! if (bitset(H_EOH, chompheader(buf, FALSE, hdrp, e))) { ! mstate = MS_BODY; ! if (tTd(30, 35)) ! printf("H_EOH, istate=%d, mstate=%d\n", istate, mstate); ! goto nextstate; ! } break; case MS_BODY: From janne@avocado.pc.helsinki.fi Sat Jul 11 00:37:45 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 11 Jul 1998 02:37:45 +0300 Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: Gergely Madarasz's message of "Sat, 11 Jul 1998 01:25:46 +0200 (METDST)" References: Message-ID: Gergely Madarasz writes: > This is a bug in sendmail, it segfaults on 8bitmime digests when sending > them to hosts which don't support 8bitmime. I already wrote about this to > the list a couple of weeks ago. Btw i thought 8.9.1 already has it fixed. Thanks a lot - seems like I should read some archives... I installed 8.9.1 just an hour ago, so haven't really given it a try yet. The problems appeared with 8.8.5. -- Janne From Gergely Madarasz Sat Jul 11 00:46:18 1998 From: Gergely Madarasz (Gergely Madarasz) Date: Sat, 11 Jul 1998 01:46:18 +0200 (METDST) Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: Message-ID: On Fri, 10 Jul 1998, Ken Manheimer wrote: > Of course, this patch doesn't help the recipient sites running sendmail > 8.8.x and 8.9.x (for some x'es). Question is, does anyone think we It causes segfault only when sendmail tries to convert it from 8bit to 7bit. So the problem could be only at recipients whose secondary MX is sendmail, the primary does not know 8bitmime, and the primary can't be reached for a while. > should we be constraining the digester to 7-bit mime messages - > presumably stripping the 8th bit from messages that have it - just for > the sake of a current bug in the most prominent MTA? I'd be loathe to That would not be a solution... just think of all non-english mailing lists. I just remembered something else about the digests... could it be possible to strip the non-essential headers from the plaintext digest ? I got lots of complaints about them since I switched from majordomo. The From: header, and the Subject: could be enough.... Greg -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From klm@python.org Sat Jul 11 00:47:02 1998 From: klm@python.org (Ken Manheimer) Date: Fri, 10 Jul 1998 19:47:02 -0400 (EDT) Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: Message-ID: On Sat, 11 Jul 1998, Gergely Madarasz wrote: > I just remembered something else about the digests... could it be possible > to strip the non-essential headers from the plaintext digest ? I got lots > of complaints about them since I switched from majordomo. The From: > header, and the Subject: could be enough.... This one is one my list - i've heard this complaint from several people. Ken From klm@python.org Sat Jul 11 00:49:51 1998 From: klm@python.org (Ken Manheimer) Date: Fri, 10 Jul 1998 19:49:51 -0400 (EDT) Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: Message-ID: On Sat, 11 Jul 1998, Gergely Madarasz wrote: > On Fri, 10 Jul 1998, Ken Manheimer wrote: > > It causes segfault only when sendmail tries to convert it from 8bit to > 7bit. So the problem could be only at recipients whose secondary MX is > sendmail, the primary does not know 8bitmime, and the primary can't be > reached for a while. Ah! That sort of thing would help explain why i've so rarely heard about problems from recipients. And it would explain why the problem would show at the mailman site - they communicate with many sites, some of which may well have the 7bit restriction. Ken From klm@python.org Sat Jul 11 00:51:25 1998 From: klm@python.org (Ken Manheimer) Date: Fri, 10 Jul 1998 19:51:25 -0400 (EDT) Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: Message-ID: One more thing re the sendmail problem - if it still does exist in 8.9.1, some of us should write sendmail.org and complain. Considering that it's a known and disruptive bug (they had it in the known-bugs list for 8.9.0), it should have been stomped! Ken From viega@list.org Sat Jul 11 00:53:05 1998 From: viega@list.org (John Viega) Date: Fri, 10 Jul 1998 16:53:05 -0700 Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: ; from Ken Manheimer on Fri, Jul 10, 1998 at 07:47:02PM -0400 References: Message-ID: <19980710165305.A651@list.org> Was it not originally this way?? When/why did it change? John On Fri, Jul 10, 1998 at 07:47:02PM -0400, Ken Manheimer wrote: > On Sat, 11 Jul 1998, Gergely Madarasz wrote: > > > I just remembered something else about the digests... could it be possible > > to strip the non-essential headers from the plaintext digest ? I got lots > > of complaints about them since I switched from majordomo. The From: > > header, and the Subject: could be enough.... > > This one is one my list - i've heard this complaint from several people. > > Ken > > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers From janne@avocado.pc.helsinki.fi Sat Jul 11 01:01:42 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 11 Jul 1998 03:01:42 +0300 Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: Ken Manheimer's message of "Fri, 10 Jul 1998 19:51:25 -0400 (EDT)" References: Message-ID: Ken Manheimer writes: > One more thing re the sendmail problem - if it still does exist in > 8.9.1, some of us should write sendmail.org and complain. Considering > that it's a known and disruptive bug (they had it in the known-bugs list > for 8.9.0), it should have been stomped! collect.c seems like having the patch included. You're right in that the problem has been very annoying. Suddenly (no more missing digests, no more mail spool fiddling) mailman feels much better. -- Janne From gorgo@caesar.elte.hu Sat Jul 11 01:04:53 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Sat, 11 Jul 1998 02:04:53 +0200 (METDST) Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: Message-ID: On Fri, 10 Jul 1998, Ken Manheimer wrote: > One more thing re the sendmail problem - if it still does exist in > 8.9.1, some of us should write sendmail.org and complain. Considering > that it's a known and disruptive bug (they had it in the known-bugs list > for 8.9.0), it should have been stomped! The changelog for 8.9.1 says it is fixed. Greg -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From klm@python.org Sat Jul 11 01:00:44 1998 From: klm@python.org (Ken Manheimer) Date: Fri, 10 Jul 1998 20:00:44 -0400 (EDT) Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: <19980710165305.A651@list.org> Message-ID: On Fri, 10 Jul 1998, John Viega wrote: > Was it not originally this way?? When/why did it change? My fault - i added in more to the headers, missing the info myself, and thinking that good MIME mua's could manage the display nicely. Oh well, i think i'll just cut them back a lot - though probably not completely... Ken From viega@list.org Sat Jul 11 01:00:18 1998 From: viega@list.org (John Viega) Date: Fri, 10 Jul 1998 17:00:18 -0700 Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: ; from Ken Manheimer on Fri, Jul 10, 1998 at 08:00:44PM -0400 References: <19980710165305.A651@list.org> Message-ID: <19980710170018.A889@list.org> Wasn't the request for on non-MIME digests? I don't mind so much w/ MIME. Also, if we reorganize a few things to avoid filtering for each message (by caching stuff), it would be acceptable to let the user set verbose headers as an option. On Fri, Jul 10, 1998 at 08:00:44PM -0400, Ken Manheimer wrote: > On Fri, 10 Jul 1998, John Viega wrote: > > > Was it not originally this way?? When/why did it change? > > My fault - i added in more to the headers, missing the info myself, and > thinking that good MIME mua's could manage the display nicely. Oh well, > i think i'll just cut them back a lot - though probably not > completely... > > Ken From klm@python.org Sat Jul 11 01:08:23 1998 From: klm@python.org (Ken Manheimer) Date: Fri, 10 Jul 1998 20:08:23 -0400 (EDT) Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: <19980710170018.A889@list.org> Message-ID: On Fri, 10 Jul 1998, John Viega wrote: > Wasn't the request for on non-MIME digests? I don't mind so much w/ > MIME. Also, if we reorganize a few things to avoid filtering for each > message (by caching stuff), it would be acceptable to let the user set > verbose headers as an option. The reason i was considering reducing the headers in both is because currently they're congruent - the same file contains them both. I don't think i'll have time to refine that very much, because there's higher priority stuff to tackle. We'll see though - eventually, messages pending digest should be stored in some kind of catalogue, enabling more discretion in their handling... Ken From gorgo@caesar.elte.hu Sat Jul 11 01:41:05 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Sat, 11 Jul 1998 02:41:05 +0200 (METDST) Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: Message-ID: On Fri, 10 Jul 1998, Ken Manheimer wrote: > On Fri, 10 Jul 1998, John Viega wrote: > > > Wasn't the request for on non-MIME digests? I don't mind so much w/ > > MIME. Also, if we reorganize a few things to avoid filtering for each > > message (by caching stuff), it would be acceptable to let the user set > > verbose headers as an option. > > The reason i was considering reducing the headers in both is because > currently they're congruent - the same file contains them both. I see... but I think it is nice to have the headers in the mime digest - it keeps the mails full, with content information, etc. The best solution would be to filter out the extra headers at digest-creation time and only when creating the plaintext digest. Greg -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From klm@python.org Sat Jul 11 01:48:51 1998 From: klm@python.org (Ken Manheimer) Date: Fri, 10 Jul 1998 20:48:51 -0400 (EDT) Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: Message-ID: On Sat, 11 Jul 1998, Gergely Madarasz wrote: > I see... but I think it is nice to have the headers in the mime digest - > it keeps the mails full, with content information, etc. The best solution > would be to filter out the extra headers at digest-creation time and only > when creating the plaintext digest. That's very likely what i'll do - if you look in mm_digest.py, there's 'present'ation method which can do all the reduction work, shouldn't be hard. Ken From gorgo@caesar.elte.hu Sun Jul 12 15:35:35 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Sun, 12 Jul 1998 16:35:35 +0200 (METDST) Subject: [Mailman-Developers] big problems Message-ID: Hello! Two of my lists arent working. The error log says: Jul 12 16:22:30 1998 post: Traceback (innermost last): post: File "/var/lib/mailman/scripts/mailowner", line 40, in ? post: current_list = maillist.MailList(sys.argv[1]) post: File "/var/lib/mailman/Mailman/maillist.py", line 64, in __init__ post: self.Load() post: File "/var/lib/mailman/Mailman/maillist.py", line 554, in Load post: raise mm_cfg.MMBadListError, 'Failed to unmarshal config info' post: AttributeError : MMBadListError What could have caused this and how do I fix it ? Greg -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From janne@avocado.pc.helsinki.fi Mon Jul 13 10:35:35 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: Mon, 13 Jul 1998 12:35:35 +0300 Subject: [Mailman-Developers] A logging bug (and a patch) Message-ID: <199807130935.MAA21245@avocado.pc.helsinki.fi> I got these when a listadmin tried to approve/discard messages: Jul 13 12:13:23 1998 admindb: Traceback (innermost last): admindb: File "/home/mailman/scripts/admindb", line 232, in ? admindb: HandleRequests(doc) admindb: File "/home/mailman/scripts/admindb", line 125, in HandleRequests admindb: list.HandleRequest(request, v, form[comment_key].value) admindb: File "/home/mailman/Mailman/mm_admin.py", line 137, in HandleRequest admindb: self.HandlePostRequest(request_data[2:], value, comment) admindb: File "/home/mailman/Mailman/mm_admin.py", line 174, in HandlePostRequ est admindb: self.LogMsg("vette", note) admindb: File "/home/mailman/Mailman/maillist.py", line 570, in LogMsg admindb: logf.write("%s\n" % (msg % args)) admindb: TypeError : not enough arguments for format string The reasons was that one of the messages had '18% grey card' on the subject line. :) Here's patch: --- mm_admin.py~ Thu Jun 4 23:12:28 1998 +++ mm_admin.py Mon Jul 13 12:31:06 1998 @@ -171,6 +171,7 @@ note = note + "\n\tHeld: %s" % data[1] if comment: note = note + "\n\tDiscarded: %s" % comment + note = string.replace(note,'%','%%') self.LogMsg("vette", note) def HandleAddMemberRequest(self, data, value, comment): ... although I'm not sure whether this is a generic enough way to handle the problem. -- Janne From gorgo@caesar.elte.hu Mon Jul 13 23:06:21 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Tue, 14 Jul 1998 00:06:21 +0200 (METDST) Subject: [Mailman-Developers] port 25 problem Message-ID: Hello! I've found another problem... if the cronjob that creates the digest runs at a time when sendmail is down (dunno why but it may happen), then it is lost. It would be nicer if mailman used sendmail directly, and not thru port 25. -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From viega@list.org Mon Jul 13 23:24:47 1998 From: viega@list.org (John Viega) Date: Mon, 13 Jul 1998 15:24:47 -0700 Subject: [Mailman-Developers] port 25 problem In-Reply-To: ; from Gergely Madarasz on Tue, Jul 14, 1998 at 12:06:21AM +0200 References: Message-ID: <19980713152447.A2069@list.org> This problem is known. Unfortunately, calling sendmail is highly unportable. The next release will queue up messages until sendmail becomes available. If I have time, you'll be able to call sendmail as instead, as an option. John On Tue, Jul 14, 1998 at 12:06:21AM +0200, Gergely Madarasz wrote: > Hello! > > I've found another problem... if the cronjob that creates the digest runs > at a time when sendmail is down (dunno why but it may happen), then it is > lost. It would be nicer if mailman used sendmail directly, and not thru > port 25. > > -- > Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org > It's practically impossible to look at a penguin and feel angry. > Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. > HuLUG: http://www.cab.u-szeged.hu/local/linux/ > > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers From klm@python.org Tue Jul 14 05:21:56 1998 From: klm@python.org (Ken Manheimer) Date: Tue, 14 Jul 1998 00:21:56 -0400 (EDT) Subject: [Mailman-Developers] Some patch for mailman In-Reply-To: Message-ID: On Wed, 1 Jul 1998, Dan Ohnesorg, admin on power wrote: > Hi everybody, Hi, dan. Sorry it's taken so long to respond - i for one haven't had much time to do a lot of pending mailman stuff, including looking at your patches, until now. > What it solves, first part of patch to remove irriting headers from messages. I dont > like to send messages like RCPT and so. Second uses DSN to send mails. This > disables (when enabled) messages like warning, message is not delivered for 4 > hours and so. Then comes some removing of winmail.dat binary attachments. I am > working on removing all unwanted parts (html, rtf) and translating national > characters into ascii, but is not complete yet. Then comes administrativ via filter, but > it not works, it worked on mailman 1.0, but I cannot bring it running on b4, You will > see, it is probably only a little bug, at least the filter shields list from administrative > messages. The main thing that interests me is the DSN capability. It may be that we'll integrate it for the next release. I'm reluctant to do any administrivia filtering that catches anything but the most mechanical administrivia - i do not want to try to catch messages like "How do i subscribe to the list?", only those that were strictly formatted and intended for the -request address. I also wouldn't recommend doing translation of stuff to ascii, or other surgery on messages. Minimum intrusion is the rule - granted, stuff like winmail.dat attachments are a nuisance, but it seems like the problem is with the origin, and not something a relatively transparent maillist should be trying to fix. ken manheimer klm@python.org From klm@python.org Tue Jul 14 05:29:18 1998 From: klm@python.org (Ken Manheimer) Date: Tue, 14 Jul 1998 00:29:18 -0400 (EDT) Subject: [Mailman-Developers] big problems In-Reply-To: Message-ID: On Sun, 12 Jul 1998, Gergely Madarasz wrote: > Two of my lists arent working. The error log says: > > Jul 12 16:22:30 1998 post: Traceback (innermost last): > post: File "/var/lib/mailman/scripts/mailowner", line 40, in ? > post: current_list = maillist.MailList(sys.argv[1]) > post: File "/var/lib/mailman/Mailman/maillist.py", line 64, in __init__ > post: self.Load() > post: File "/var/lib/mailman/Mailman/maillist.py", line 554, in Load > post: raise mm_cfg.MMBadListError, 'Failed to unmarshal config info' > post: AttributeError : MMBadListError > > What could have caused this and how do I fix it ? Sounds like the config.db for the lists somehow got corrupted. I haven't seen this happen to any of the python.org or other lists i run (mostly 1.0b4, some with the current development code). Did you find any prior errors in the error log? Any abnormal incidents on the host leading up to it?? If you'd like, you could send me a (mime-attached or uuencoded tar archive) copy of the config.db files for each of the lists, and i can see if there's anything i can glean, and salvalge, from them... Ken Manheimer klm@python.org 703 620-8990 x268 (orporation for National Research |nitiatives # If you appreciate Python, consider joining the PSA! # # . # From Dan@feld.cvut.cz Tue Jul 14 09:25:46 1998 From: Dan@feld.cvut.cz (Dan Ohnesorg, admin on power) Date: Tue, 14 Jul 1998 10:25:46 +0200 Subject: [Mailman-Developers] Some patch for mailman In-Reply-To: References: Message-ID: <212401917E1@power.feld.cvut.cz> On 14 Jul 98, at 0:21, Ken Manheimer wrote: > On Wed, 1 Jul 1998, Dan Ohnesorg, admin on power wrote: Hi Ken, > > > Hi everybody, > > Hi, dan. Sorry it's taken so long to respond - i for one haven't had > much time to do a lot of pending mailman stuff, including looking at > your patches, until now. No problemo. > I'm reluctant to do any administrivia filtering that catches anything > but the most mechanical administrivia - i do not want to try to catch > messages like "How do i subscribe to the list?", only those that were > strictly formatted and intended for the -request address. Yes it is that, what my patch mades, it looks on first word on first 10 lines in message and when it founds command for listserv, it redirects the message. I think it will work fine, but I have following problem.. Jul 03 13:29:51 1998 post: Traceback (innermost last): post: File "/home/mailman/scripts/post", line 102, in ? post: current_list.ParseMailCommands() post: File "/home/mailman/Mailman/mm_mailcmd.py", line 80, in ParseMailCommands post: sender = string.lower(mail.GetSender()) post: File "/home/mailman/Mailman/mm_message.py", line 115, in GetSender post: return string.lower(mail_address) post: TypeError : read-only buffer, None I think there is nothing bad, return modifies nothing. > > I also wouldn't recommend doing translation of stuff to ascii, or other > surgery on messages. Minimum intrusion is the rule - granted, stuff > like winmail.dat attachments are a nuisance, but it seems like the > problem is with the origin, and not something a relatively transparent > maillist should be trying to fix. Yes it is problem in origin. Problem in origin is also that smail many years corupts messages consisting CRLF.CRLF in body and mailman includes fix for that. I have list with 500 subscribers and 50 mesages per day, when I shall distribute unwanted parts of this messages, I am worried. It takes many MB, winmail.dat is many times bigger than mail itself. It makes archive big and slowes searching or at least indexing. And it slowes delivery. Many peoples cannot read correctly mesages with ms-tnef and html part and I will give them posibility to become readable messages. My vision is, that there should be posibility to send command like set ascii to become pure ascii messages. I hope You will also include that part, which removes some headers, like confirm-delivery-to:, I will send more patterns soon. Yesterday I have shown RFC for delivery confirmation messages and there are some headers, which are not intended for public redistribute over maillists. cheers dan ________________________________________ DDDDDD DD DD Dan Ohnesorg, supervisor on POWER DD OOOO Dan@feld.cvut.cz DD OODDOO Dep. of Power Engineering DDDDDD OO CVUT FEL Prague, Bohemia OO OO work: +420 2 24352785;+420 2 24972109 OOOO home: +420 311 679679;+420 311 679311 ________________________________________ Kdo se zahledi, neprokoukne. From gorgo@caesar.elte.hu Tue Jul 14 10:33:58 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Tue, 14 Jul 1998 11:33:58 +0200 (METDST) Subject: [Mailman-Developers] big problems In-Reply-To: Message-ID: On Tue, 14 Jul 1998, Ken Manheimer wrote: > > Jul 12 16:22:30 1998 post: Traceback (innermost last): > > post: File "/var/lib/mailman/scripts/mailowner", line 40, in ? > > post: current_list = maillist.MailList(sys.argv[1]) > > post: File "/var/lib/mailman/Mailman/maillist.py", line 64, in __init__ > > post: self.Load() > > post: File "/var/lib/mailman/Mailman/maillist.py", line 554, in Load > > post: raise mm_cfg.MMBadListError, 'Failed to unmarshal config info' > > post: AttributeError : MMBadListError > > > > What could have caused this and how do I fix it ? > > Sounds like the config.db for the lists somehow got corrupted. I > haven't seen this happen to any of the python.org or other lists i run > (mostly 1.0b4, some with the current development code). Did you find > any prior errors in the error log? Any abnormal incidents on the host > leading up to it?? It seems the other admin of the server has done something that crashed the server, so the file corrupted... fortunatelly there was config.db.last Greg -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From janne@avocado.pc.helsinki.fi Tue Jul 14 11:46:18 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 14 Jul 1998 13:46:18 +0300 Subject: [Mailman-Developers] Some patch for mailman In-Reply-To: "Dan Ohnesorg, admin on power"'s message of "Tue, 14 Jul 1998 10:25:46 +0200" References: <212401917E1@power.feld.cvut.cz> Message-ID: "Dan Ohnesorg, admin on power" writes: > I have list with 500 subscribers and 50 mesages per day, when I shall distribute > unwanted parts of this messages, I am worried. It takes many MB, winmail.dat is > many times bigger than mail itself. You can filter on the basis of headers, and reject messages which contain HTML or WINMAIL stuff. We do that and it works well. If you start doing automatically things like removing HTML, there's no end to it. It's better to educate subscribers to behave properly. -- Janne From viega@list.org Tue Jul 14 14:56:32 1998 From: viega@list.org (John Viega) Date: Tue, 14 Jul 1998 06:56:32 -0700 Subject: [Mailman-Developers] big problems In-Reply-To: ; from Gergely Madarasz on Tue, Jul 14, 1998 at 11:33:58AM +0200 References: Message-ID: <19980714065632.B8966@list.org> On Tue, Jul 14, 1998 at 11:33:58AM +0200, Gergely Madarasz wrote: > On Tue, 14 Jul 1998, Ken Manheimer wrote: > > It seems the other admin of the server has done something that crashed the > server, so the file corrupted... fortunatelly there was config.db.last Ah, I'm glad this feature works :) Perhaps if the file can't be loaded, it can try the last file. John From gorgo@caesar.elte.hu Tue Jul 14 15:15:23 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Tue, 14 Jul 1998 16:15:23 +0200 (METDST) Subject: [Mailman-Developers] big problems In-Reply-To: <19980714065632.B8966@list.org> Message-ID: On Tue, 14 Jul 1998, John Viega wrote: > On Tue, Jul 14, 1998 at 11:33:58AM +0200, Gergely Madarasz wrote: > > On Tue, 14 Jul 1998, Ken Manheimer wrote: > > > > It seems the other admin of the server has done something that crashed the > > server, so the file corrupted... fortunatelly there was config.db.last > > Ah, I'm glad this feature works :) Perhaps if the file can't be > loaded, it can try the last file. That would be nice. And warn the admin, of course. Btw it seems I have lost several digests because sendmail did not accept connections on port 25 at that time... it could be a config option not to connect to port 25 but use sendmail -bs so not much should be changed (sendmail -bs talks smtp), just the invocation. -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From viega@list.org Tue Jul 14 15:10:04 1998 From: viega@list.org (John Viega) Date: Tue, 14 Jul 1998 07:10:04 -0700 Subject: [Mailman-Developers] big problems In-Reply-To: ; from Gergely Madarasz on Tue, Jul 14, 1998 at 04:15:23PM +0200 References: <19980714065632.B8966@list.org> Message-ID: <19980714071004.D8966@list.org> On Tue, Jul 14, 1998 at 04:15:23PM +0200, Gergely Madarasz wrote: > > Btw it seems I have lost several digests because sendmail did not accept > connections on port 25 at that time... it could be a config option not to > connect to port 25 but use sendmail -bs so not much should be changed > (sendmail -bs talks smtp), just the invocation. Yeah, this problem is becoming a FAQ. There will be a solution to the problem in the next release, and if I have time, I'll allow an external command to work instead. John From gorgo@caesar.elte.hu Mon Jul 20 22:33:48 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Mon, 20 Jul 1998 23:33:48 +0200 (METDST) Subject: [Mailman-Developers] loosing mail Message-ID: Hello! I'm still loosing digests because mailman wants to use port 25... :( This is a Bad Thing (TM). Any dates about the new release which would fix this? Or is there a patch around for 1.0b4 ? I don't want to switch back to majordomo now :((( -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From klm@python.org Mon Jul 20 23:19:12 1998 From: klm@python.org (Ken Manheimer) Date: Mon, 20 Jul 1998 18:19:12 -0400 (EDT) Subject: [Mailman-Developers] loosing mail In-Reply-To: Message-ID: On Mon, 20 Jul 1998, Gergely Madarasz wrote: > I'm still loosing digests because mailman wants to use port 25... :( > This is a Bad Thing (TM). Any dates about the new release which would fix > this? Or is there a patch around for 1.0b4 ? I don't want to switch back > to majordomo now :((( I'd wait to see what john says - he's working on the queuing stuff - but failing a near fix, you could look at switching back to 1.0b3. The tricky thing is, i'm not sure the 1.0b4 list data structures (config.db) are compatable w/1.0b3, so you might need a conversion function to revert it - changing things like paths, etc. Whatever you do, if you do fool around with reverting, make backup copies of your stuff before tinkering... Ken klm@python.org From viega@list.org Mon Jul 20 23:39:18 1998 From: viega@list.org (John Viega) Date: Mon, 20 Jul 1998 15:39:18 -0700 Subject: [Mailman-Developers] loosing mail In-Reply-To: ; from Ken Manheimer on Mon, Jul 20, 1998 at 06:19:12PM -0400 References: Message-ID: <19980720153918.D13724@list.org> I'm going to try to ready something for tomorrow night. After that, we might try to release weekly snapshots, assuming progress gets made in that week. John On Mon, Jul 20, 1998 at 06:19:12PM -0400, Ken Manheimer wrote: > On Mon, 20 Jul 1998, Gergely Madarasz wrote: > > > I'm still loosing digests because mailman wants to use port 25... :( > > This is a Bad Thing (TM). Any dates about the new release which would fix > > this? Or is there a patch around for 1.0b4 ? I don't want to switch back > > to majordomo now :((( > > I'd wait to see what john says - he's working on the queuing stuff - but > failing a near fix, you could look at switching back to 1.0b3. The > tricky thing is, i'm not sure the 1.0b4 list data structures (config.db) > are compatable w/1.0b3, so you might need a conversion function to > revert it - changing things like paths, etc. Whatever you do, if you do > fool around with reverting, make backup copies of your stuff before > tinkering... > > Ken > klm@python.org > > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Mon Jul 20 23:53:41 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 20 Jul 1998 18:53:41 -0400 (EDT) Subject: [Mailman-Developers] loosing mail References: <19980720153918.D13724@list.org> Message-ID: <13747.51829.799529.285905@anthem.cnri.reston.va.us> >>>>> "JV" == John Viega writes: JV> I'm going to try to ready something for tomorrow night. After JV> that, we might try to release weekly snapshots, assuming JV> progress gets made in that week. I agree. I haven't had time to catch up after vaca, but our montra should be: release early and often! :-) From gorgo@caesar.elte.hu Thu Jul 23 18:05:38 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Thu, 23 Jul 1998 19:05:38 +0200 (METDST) Subject: [Mailman-Developers] URGENT!!!! security problems Message-ID: Hello! There are BIG security problems with mailman. For example a list administrator can subscribe an "email address" like this with mass subscribe: `touch /tmp/gotcha` Then when someone sends mail to the list, the command is executed... this means any list administrator can get access to user running mailman on the list server. I could not achieve the same when trying to subscribe as a normal user, but i cannot say that it is safe. This needs a very urgent fix. Greg Ps. thanks to Endre Hirling for pointing this problem out to me -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From John@list.org Thu Jul 23 18:27:08 1998 From: John@list.org (John Viega) Date: Thu, 23 Jul 1998 10:27:08 -0700 Subject: [Mailman-Developers] URGENT!!!! security problems In-Reply-To: ; from Gergely Madarasz on Thu, Jul 23, 1998 at 07:05:38PM +0200 References: Message-ID: <19980723102708.A13639@viega.org> Actually, that's a known issue. Security stuff is on our todo list, but not much thought has gone into it yet. I hadn't actually put too high a priority on it at this point, since you only need to trust list administrators. It was certainly expected to be done before beta. However, if you want it in sooner, we can move it up. Or, for an even quicker solution, you or someone else could submit patches to either b4, or b5, which will come out perhaps today or tomorrow, but if not, on Monday for sure. It depends on how much time I have to do testing... John On Thu, Jul 23, 1998 at 07:05:38PM +0200, Gergely Madarasz wrote: > Hello! > > There are BIG security problems with mailman. For example a list > administrator can subscribe an "email address" like this with mass > subscribe: > > `touch /tmp/gotcha` > > Then when someone sends mail to the list, the command is executed... this > means any list administrator can get access to user running mailman > on the list server. I could not achieve the same when trying to > subscribe as a normal user, but i cannot say that it is safe. This needs a > very urgent fix. > > Greg > > Ps. thanks to Endre Hirling for pointing this problem > out to me > > -- > Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org > It's practically impossible to look at a penguin and feel angry. > Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. > HuLUG: http://www.cab.u-szeged.hu/local/linux/ > > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers From scott@chronis.icgroup.com Fri Jul 24 04:12:28 1998 From: scott@chronis.icgroup.com (Scott) Date: Thu, 23 Jul 1998 23:12:28 -0400 Subject: [Mailman-Developers] an opinion about using port 25 Message-ID: <19980723231228.64640@chronis.icgroup.com> Something's been bothering me about the use of connecting to port 25 to deliver mail. The goal of this endeavor, if i remember correctly, was to make mailman more portable in it's interface to MTA's. However, I think that it may well make that problem even worse, and that it lies outside what mailman should be doing. Here's the argument: mailman is a mailing list manager, not an MTA. If mailman developers decide to make delivery occur by SMTP, it has to do a LOT of the work that an MTA should be doing: queuing messages, retrying every so often, bouncing messages with appropriate messages under appropriate circumstances (like deferral messages every 4 hours, etc). All this should be the work of the MTA. I also think that it will eventually exacerbate the problems of portability. As a part of test group for a new MTA, and an administrator of a qmail and a sendmail system, I know many work-years of labor goes into making an MTA be able to successfully deliver mail to all the other MTA's out there. This happens because different MTAs act very differently. There are still problems occuring between code as mature as qmail and other MTA's like certain microsoft based products (postoffice, LSOFT for nt, etc). Do we really want to take on that burden? There are other ways we could pursue this. There are basically 2 interfaces to an MTA mailman has to consider: updating aliases and delivering messages. For each of these interfaces, we could create a class hierarchy into which mailman's communication with new MTA's could be easily dropped. Such a structure, coupled with good documentation about how to add support for a new MTA seems to me like it will go further faster than putting a lot of work into SMTP transactions. Such an approach could even include smtp transactions, as a bonus for the daring or those who want mail delivered via a separate machine than the one on which the list manager resides. As far as portability goes, and as far allowing mailman developers to focus on what a list manager should do, i really think that we would do better not depending on a universally reliable way of doing smtp transactions. scott From klm@python.org Fri Jul 24 23:38:12 1998 From: klm@python.org (Ken Manheimer) Date: Fri, 24 Jul 1998 18:38:12 -0400 (EDT) Subject: [Mailman-Developers] an opinion about using port 25 In-Reply-To: <19980723231228.64640@chronis.icgroup.com> Message-ID: On Thu, 23 Jul 1998, Scott wrote: > Something's been bothering me about the use of connecting to port 25 to > deliver mail. > > The goal of this endeavor, if i remember correctly, was to make > mailman more portable in it's interface to MTA's. However, I think > that it may well make that problem even worse, and that it lies > outside what mailman should be doing. > > Here's the argument: > > mailman is a mailing list manager, not an MTA. If mailman developers > decide to make delivery occur by SMTP, it has to do a LOT of the work > that an MTA should be doing: queuing messages, retrying every so > often, bouncing messages with appropriate messages under appropriate > circumstances (like deferral messages every 4 hours, etc). All this > should be the work of the MTA. > > I also think that it will eventually exacerbate the problems of > portability. As a part of test group for a new MTA, and an > administrator of a qmail and a sendmail system, I know many > work-years of labor goes into making an MTA be able to successfully > deliver mail to all the other MTA's out there. This happens because > different MTAs act very differently. There are still problems > occuring between code as mature as qmail and other MTA's like certain > microsoft based products (postoffice, LSOFT for nt, etc). > > Do we really want to take on that burden? Most definitely not! While i adamantly agree that Mailman should not be taking over the duties of an MTA, i do not believe that the recent change amounts to that. The change is in the way that Mailman passes messages to the *local* MTA - it uses SMTP instead of execing the MTA program. This falls far, far short of the general problem of delivery to a general host out on the net. The local MTA still handles all the challenges of getting the messages to the remote site! There are a few significant benefits to this change. Directly contrary to Scott's next point, this drastically reduces portability burdens, because Mailman doesn't need to know *anything* about the specific MTA the local host is running, except that it obeys SMTP. Another big benefit actually addresses the concerns Gergely Madarasz (urgently) raised yesterday. By using the specialized protocol, we don't need to expose any of the addresses or other incidentals to processing by the system shell. (The addresses were still being exposed in other popen's, further upstream, but i changed that in the development code, which should be released soon. I did a quick check for other os.popen's and and os.systems, and most looked safe, but we still have yet to do a thorough examination for security sake.) There are related literal-mangling problems associated with exposing strings to the shell, which we also circumvent by direct protocol transmission. This change may also enable us to exploit advanced SMTP capabilities, like the DSN mod that dan ohnesorg has proposed (inhibiting those annoying "Warning: not yet delivered after 4 hours, will keep trying (and telling you about it)" messages). There are two drawbacks i can see to this approach, both easily surmountable. One is that we *do* have to make provisions for systems where the MTA is not always available. This amounts to a drastically scaled-down version of the general delivery-to-an-unavailable host, and has none of the nuances of the more general problem. It is addressed in the working code. The other is in handling delivery failures for destinations that happen to be local to the local MTA. These are the only deliveries that will be immediately recognized and refused. In this case we don't get the benefit of bounce messages to recognize bad recipients, and we have to make sure that the deliveries to valid recipients on the local host are not disrupted. The latter part has been taken care of in the working copy, and the former part has to be, but no great disruption is caused by it, in any case. > There are other ways we could pursue this. There are basically 2 > interfaces to an MTA mailman has to consider: updating aliases and > delivering messages. For each of these interfaces, we could create a > class hierarchy into which mailman's communication with new MTA's > could be easily dropped. Such a structure, coupled with good > documentation about how to add support for a new MTA seems to me like > it will go further faster than putting a lot of work into SMTP > transactions. Such an approach could even include smtp transactions, > as a bonus for the daring or those who want mail delivered via a > separate machine than the one on which the list manager resides. I don't agree. I'd rather solve, once and for all, connecting via SMTP to the local MTA, and having to handle queueing messages at times the MTA is unavailable, than developing a general plug in framework for a command-based interface with every MTA that's ever going to come down the road. That doesn't sound like an tidy problem to me. Ken From klm@python.org Fri Jul 24 23:41:17 1998 From: klm@python.org (Ken Manheimer) Date: Fri, 24 Jul 1998 18:41:17 -0400 (EDT) Subject: [Mailman-Developers] URGENT!!!! security problems In-Reply-To: <19980723102708.A13639@viega.org> Message-ID: On Thu, 23 Jul 1998, John Viega wrote: > Actually, that's a known issue. Security stuff is on our todo list, > but not much thought has gone into it yet. I hadn't actually put too > high a priority on it at this point, since you only need to trust list > administrators. It was certainly expected to be done before beta. > However, if you want it in sooner, we can move it up. Or, for an even > quicker solution, you or someone else could submit patches to either > b4, or b5, which will come out perhaps today or tomorrow, but if not, > on Monday for sure. It depends on how much time I have to do > testing... As i mentioned in my prior message, this has been addressed in the working copy, so we're no longer interested in other patches for it. (We will be interested in exercise of the fixes, of course, once they're released...) Ken klm@python.org From gorgo@caesar.elte.hu Fri Jul 24 23:59:24 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Sat, 25 Jul 1998 00:59:24 +0200 (METDST) Subject: [Mailman-Developers] an opinion about using port 25 In-Reply-To: Message-ID: On Fri, 24 Jul 1998, Ken Manheimer wrote: > The change is in the way that Mailman passes messages to the *local* MTA > - it uses SMTP instead of execing the MTA program. This falls far, far > short of the general problem of delivery to a general host out on the > net. The local MTA still handles all the challenges of getting the > messages to the remote site! > > There are a few significant benefits to this change. Directly contrary > to Scott's next point, this drastically reduces portability burdens, > because Mailman doesn't need to know *anything* about the specific MTA > the local host is running, except that it obeys SMTP. As I said in one of my previous postings... sendmail can be called from the command line to talk SMTP just like as connected to port 25 (sendmail -bs). I expect most other MTA's have the same features, with perhaps a bit different command line. So the only difference between using a local MTA and connecting to port 25 would be to open a two way pipe to 'sendmail -bs' or whatever (all sendmail-compatible mta-s, like exim or smail should have sendmail -bs) instead of connecting to port 25. All the rest is the same. So the only change needed here would be in the connect function of smtplib -> not a mailman issue but a python issue :) This would be much-much nicer than mailman trying to queue mails. Greg -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From gorgo@caesar.elte.hu Sat Jul 25 00:02:35 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Sat, 25 Jul 1998 01:02:35 +0200 (METDST) Subject: [Mailman-Developers] an opinion about using port 25 In-Reply-To: Message-ID: On Sat, 25 Jul 1998, Gergely Madarasz wrote: > 'sendmail -bs' or whatever (all sendmail-compatible mta-s, like exim or > smail should have sendmail -bs) instead of connecting to port 25. All the Of course, all these optional, depending on some parameters passed to smtplib or some defaults... with fallback to port 25. -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From scott@chronis.icgroup.com Sat Jul 25 18:09:57 1998 From: scott@chronis.icgroup.com (Scott) Date: Sat, 25 Jul 1998 13:09:57 -0400 Subject: [Mailman-Developers] [gorgo@caesar.elte.hu: Re: [Mailman-Developers] URGENT!!!! security problems] Message-ID: <19980725130957.37546@chronis.icgroup.com> -----Forwarded message from Gergely Madarasz ----- Found the problem. ValidEmail is called only from AddMember, not from ApprovedAddMember. So the listowner can subscribe invalid addresses. -------------------- mmm... something must not have made it's way into the patches for 1.0b4. my working copy has ValidEmail called in ApprovedAddMember but 1.0b4 does not. don't know if that was my fault or not, but i think adding a ValidEmail call to ApprovedAddMember is the right way to go: it should be harmless when ApprovedAddMember is called from the mail_cmd interface since it's already been called in AddMember, and it does fix the security problem. scott From John@list.org Mon Jul 27 02:29:45 1998 From: John@list.org (John Viega) Date: Sun, 26 Jul 1998 18:29:45 -0700 Subject: [Mailman-Developers] an opinion about using port 25 In-Reply-To: ; from Gergely Madarasz on Sat, Jul 25, 1998 at 12:59:24AM +0200 References: Message-ID: <19980726182945.A27993@viega.org> On Sat, Jul 25, 1998 at 12:59:24AM +0200, Gergely Madarasz wrote: > > As I said in one of my previous postings... sendmail can be called from > the command line to talk SMTP just like as connected to port 25 > (sendmail -bs). I expect most other MTA's have the same features, with > perhaps a bit different command line. That's definitely not the case for a few MTA's, and it's definitely not something I would want to count on even if it were. From gorgo@caesar.elte.hu Mon Jul 27 03:09:47 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Mon, 27 Jul 1998 04:09:47 +0200 (METDST) Subject: [Mailman-Developers] an opinion about using port 25 In-Reply-To: <19980726182945.A27993@viega.org> Message-ID: On Sun, 26 Jul 1998, John Viega wrote: > > On Sat, Jul 25, 1998 at 12:59:24AM +0200, Gergely Madarasz wrote: > > > > As I said in one of my previous postings... sendmail can be called from > > the command line to talk SMTP just like as connected to port 25 > > (sendmail -bs). I expect most other MTA's have the same features, with > > perhaps a bit different command line. > > That's definitely not the case for a few MTA's, and it's definitely > not something I would want to count on even if it were. Don't count on it, just make it an option :) I'd use it here and now. Unfortunatelly I'm just a beginner in python... -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From Dan@feld.cvut.cz Sat Jul 25 22:23:03 1998 From: Dan@feld.cvut.cz (Dan Ohnesorg, admin of POWER) Date: Sat, 25 Jul 1998 23:23:03 +0200 Subject: [Mailman-Developers] an opinion about using port 25 In-Reply-To: References: Message-ID: <3272A6A6B51@power.feld.cvut.cz> On 25 Jul 98, at 0:59, Gergely Madarasz wrote: > As I said in one of my previous postings... sendmail can be called from > the command line to talk SMTP just like as connected to port 25 > (sendmail -bs). I expect most other MTA's have the same features, with > perhaps a bit different command line. So the only difference between using > a local MTA and connecting to port 25 would be to open a two way pipe to > 'sendmail -bs' or whatever (all sendmail-compatible mta-s, like exim or > smail should have sendmail -bs) instead of connecting to port 25. All the > rest is the same. So the only change needed here would be in the connect > function of smtplib -> not a mailman issue but a python issue :) > This would be much-much nicer than mailman trying to queue mails. I have made patch, which uses delivery status notification. This will be probably included in some of next revision. I have not found some posibility, how detect ob MTA knows this feature, other than parsing respond to EHLO request. Delivery status notification is very nice feature, I am using only notify=failure and the list is shielded before warnigs like, mail was not delivered within 4 hours and so. cheers dan ________________________________________ DDDDDD DD DD Dan Ohnesorg, supervisor on POWER DD OOOO Dan@feld.cvut.cz DD OODDOO Dep. of Power Engineering DDDDDD OO CTU FEL Prague, Bohemia OO OO work: +420 2 24352785;+420 2 24972109 OOOO home: +420 311 679679;+420 311 679311 ________________________________________ Pesimista vidi v ementalskem syru jen ty diry. From dragondm@delta.integral.org Mon Jul 27 11:20:18 1998 From: dragondm@delta.integral.org (The Dragon De Monsyne) Date: Mon, 27 Jul 1998 05:20:18 -0500 (CDT) Subject: [Mailman-Developers] an opinion about using port 25 In-Reply-To: <3272A6A6B51@power.feld.cvut.cz> Message-ID: On Sat, 25 Jul 1998, Dan Ohnesorg, admin of POWER wrote: > On 25 Jul 98, at 0:59, Gergely Madarasz wrote: > > > As I said in one of my previous postings... sendmail can be called from > > the command line to talk SMTP just like as connected to port 25 > > (sendmail -bs). I expect most other MTA's have the same features, with > > perhaps a bit different command line. So the only difference between using > > a local MTA and connecting to port 25 would be to open a two way pipe to > > 'sendmail -bs' or whatever (all sendmail-compatible mta-s, like exim or > > smail should have sendmail -bs) instead of connecting to port 25. All the > > rest is the same. So the only change needed here would be in the connect > > function of smtplib -> not a mailman issue but a python issue :) > > This would be much-much nicer than mailman trying to queue mails. > > I have made patch, which uses delivery status notification. This > will be probably included in some of next revision. I have not > found some posibility, how detect ob MTA knows this feature, > other than parsing respond to EHLO request. Delivery status > notification is very nice feature, I am using only notify=failure and > the list is shielded before warnigs like, mail was not delivered > within 4 hours and so. hmmm... Well, parsing the ehlo responce _is_ the proper way to detect support for any esmtp feature, like DSN. I also want to point out that the latest version of the smtplib included in the python distribution (which is NOT the same as mailman's smtplib) has full ESMTP support. This latest version (http://www.integral.org/~dragondm/python/smtplib.py) will be the smtplib included in the python 1.5.2 distribution. Also, unless someone else does it first, as soon as I can get the latest 1.0b5 code [1], I will be submitting patches for mailman to substitute this smtplib for the one currently included with mailman. The reason for that is that way, any improvements/bugfixes to the module could eventually be folded into the next python distribution. Now, as for 'sendmail -bs' well, yes you could do that. with the python smtplib, it would be a matter of subclassing smtplib.SMTP and overriding the methods that open, read from, and write to the socket, however I would reccomend against it. If the local smtp listener is refusing messages, 9 times out of ten there is a good reason for it (perhaps the server's overloaded). The best choice is for mailman to queue the message, and fer a cron job or such to try again later. Port 25 smtp is the 'universal' interface for mta's, and trying to cater to everything else out there is asking fer coding nightmares. Notes: [1] Erm, whhen's this going to be out? What happened to 'Release early, release often?' I've had things I would have liked to have coded and submitted by now, but I've been holding off on fer nearly a month wating for the latest code. Mebbe we need stable/unstable tracks like the linux kernel? With unstable releases VERY often. -The Dragon De Monsyne From John@list.org Mon Jul 27 14:55:13 1998 From: John@list.org (John Viega) Date: Mon, 27 Jul 1998 06:55:13 -0700 Subject: [Mailman-Developers] an opinion about using port 25 In-Reply-To: ; from The Dragon De Monsyne on Mon, Jul 27, 1998 at 05:20:18AM -0500 References: <3272A6A6B51@power.feld.cvut.cz> Message-ID: <19980727065513.A3254@viega.org> On Mon, Jul 27, 1998 at 05:20:18AM -0500, The Dragon De Monsyne wrote: > > Notes: > [1] Erm, whhen's this going to be out? What happened to 'Release > early, release often?' I've had things I would have liked to have coded > and submitted by now, but I've been holding off on fer nearly a month > wating for the latest code. Mebbe we need stable/unstable tracks like the > linux kernel? With unstable releases VERY often. I almost resent this comment. I'd expect you to have a bit more consideration and tolerance. We said we'd *try* to release last week, and once we did, we'd release more often. However, we were not willing to release at all until we got something that worked for some reasonable value of working. Please also be considerate to the fact that we don't have as much time as we'd like to work on this project. I'm sorry if you feel frustrated; however, we have said in the past that we would provide you with a more current snapshot on request. I would not have refused any resonable request for a snapshot from someone interested in helping out. Some sort of private communication would have been a far more apropriate forum, until that avenue proved futile. From John@list.org Tue Jul 28 00:03:21 1998 From: John@list.org (John Viega) Date: Mon, 27 Jul 1998 16:03:21 -0700 Subject: [Mailman-Developers] Whoops Message-ID: <19980727160321.A9180@viega.org> Sorry if there were multiple autogened messages from me. I only meant to send the first; I forgot to change the target address before sending the rest. John From John@list.org Tue Jul 28 00:04:31 1998 From: John@list.org (John Viega) Date: Mon, 27 Jul 1998 16:04:31 -0700 Subject: [Mailman-Developers] Hmm... Message-ID: <19980727160431.A9200@viega.org> It seems none of those messages came through anyway. Anyway, if you do happen to see multiple messages, please disregard. From John Viega Tue Jul 28 00:13:08 1998 From: John Viega (John Viega) Date: Mon, 27 Jul 1998 16:13:08 -0700 Subject: [Mailman-Developers] ANNOUNCE: Mailman 1.0b5 released Message-ID: <19980727161308.A9289@viega.org> Well, for some reason the automated mail gets to me, but not to the list. But if I send mail to the list manually it goes right through. Since I don't have time to look at it, following is the announcement sent manually. Please forgive me if the autogenerated stuff eventually does show up. ANNOUNCE: Mailman 1.0b5 release Version 1.0b5 of the Mailman mailing list manager is now available from the Mailman web page: http://www.list.org/ Via ftp, the release is available at: ftp://www.list.org/pub/mailman/mailman-1.0b5.tar.gz New in this version: - New file locking that should be portable and work w/ NFS. - Better use of packages. - Better error logging and reporting. - Less startup overhead. - Various and sundry bug fixes. Please be sure to read the README file after downloading. John Viega From John@list.org Tue Jul 28 00:23:15 1998 From: John@list.org (John Viega) Date: Mon, 27 Jul 1998 16:23:15 -0700 Subject: [Mailman-Developers] Release stability Message-ID: <19980727162315.A9425@viega.org> We're going to try to test stuff as we release it. However, in these betas, we're not going to garuntee there isn't a major show-stopper. If someone finds one, let us know, and we'll put out a new release as soon as we fix it, now that there's a release tool. John From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Tue Jul 28 00:39:10 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 27 Jul 1998 19:39:10 -0400 (EDT) Subject: [Mailman-Developers] Release stability References: <19980727162315.A9425@viega.org> Message-ID: <13757.3998.707994.72844@anthem.cnri.reston.va.us> >>>>> "JV" == John Viega writes: JV> We're going to try to test stuff as we release it. However, JV> in these betas, we're not going to garuntee there isn't a JV> major show-stopper. JV> If someone finds one, let us know, and we'll put out a new JV> release as soon as we fix it, now that there's a release tool. I also hope to have public read-only CVS sources and CVSweb access available within the week, for those of you who like to stay on the bleeding edge. Stay tuned. -Barry From John@list.org Mon Jul 27 23:53:23 1998 From: John@list.org (John@list.org) Date: Mon, 27 Jul 1998 15:53:23 -0700 Subject: [Mailman-Developers] ANNOUNCE: Mailman 1.0b5 release Message-ID: <199807272253.PAA09076@lima.mudlib.org> Version 1.0b5 of the Mailman mailing list manager is now available from the Mailman web page: http://www.list.org/ Via ftp, the release is available at: ftp://www.list.org/pub/mailman/mailman-1.0b5.tar.gz New in this version: New in 1.0b5: - New file locking that should be portable and work w/ NFS. - Better use of packages. - Better error logging and reporting. - Less startup overhead. - Various and sundry bug fixes. 1.0b4 - A configure script for easy installation (Barry Warsaw) - The ability to install Mailman to locations other than /home/mailman (Barry Warsaw) - Use cookies on the admin pages (also hides admin pages from others) (Scott Cotton) - Subscription requests send a request for confirmation, which may be done by simply replying to the message (Scott Cotton) - Facilities for gating mail to a newsgroup, and for gating a newsgroup to a mailing list (John Viega) - Contact the SMTP port instead of calling sendmail (primarily for portability) (John Viega) - Changed all links on web pages to relative links where appropriate. (John Viega) - Use MD5 if crypt is not available (John Viega) - Lots of fixing up of bounce handling (Ken Manheimer) - General UI polishing (Ken Manheimer) - mm_html: Make it prominent when the user's delivery is disabled on his option page. (Ken Manheimer) - mallist:DeleteMember() Delete the option setings if any. (Ken Manheimer) DONE for mailman 1.0b3 1.0b3 (05/03/1998) All changes by klm@python.org (ken manheimer) Items marked by an '*' asterisk have greater operational impact. * mm_message:Deliverer.DeliverToList() added missing newline between the headers and message body. Without it, any sequence of initial body lines that _looked_ like headers ("Sir: Please excuse my impertinence, but") got treated like headers. * Fixed typo which broke subscription acknowledgement message (thanks to janne sinkonen for pointing this out promptly after release). (Anyone who applied my intermediate patch will probably see this one trigger patch'es reversed-patch detector...) * Fixed cgi-wrapper.c so it doesn't segfault when invoked with improper uid or gid, and generally wrappers are cleaned up a bit. * Prevented delivery-failure notices for misdirected subscribe- confirmation requests from bouncing back to the -request addr, and then being treated as failing requests. Implemented two measures. Set the reply-to for the confirmation- request to the -request addr, and the sender to be the list admin. This way, bounces go to list admin instead of to -request addr. (Using the errors-to header wasn't sufficient. Thanks, barry, for pointing out the use of sender here.) Second, ignore any mailcommands coming from postmaster or non-login system type accounts (mailer-daemon, daemon, postoffice, etc.) * Reenabled admin setting of web_page_url - crucial for having lists use alternate names of a host that occupies multiple addresses. * Fixed and refined admin-options help mechanism. Top-level visit to general-category (where the "general" isn't in the URL) was broken. New help presentation shows the same row that shows on the actual options page. * cron/crontab.in crontab template had wrong name for senddigests. * Default digest format setting, as distributed, is now non-MIME, on urging of reasoned voices asserting that there are still enough bad MIME implementations in the world to be a nuisance to too many users if MIME is the default. Sigh. * MIME digests now preserve the structure of MIME postings, keeping attachments as attachments, etc. They also are more structured in general. * Added README instructions explaining how to determine the right UID and GID settings for the wrapper executables, and improved some of the explanations about exploratory interaction w/mailman. * Removed the constraint that subscribers have their domain included in a static list in the code. We might want to eventually reincorporate the check for the sake of a warning message, to give a heads up to the subscriber, but try delivery anyway... - Added missing titles to error docs. - Improved several help details, including particularly explaining better how real_name setting is used. - Strengthened admonition against setting reply_goes_to_list. - Added X-BeenThere header to postings for the sake of prevention of external mail loops. - Improved handling of bounced messages to better recognize members address, and prevent duplicate attempts to react (which could cause superfluous notices to administrator). - Added __delitem__ method to mm_message.OutgoingMessage, to fix the intermediate patch posted just before this one. - Using keyword substitution format for more message text (ie, "substituting %(such)s into text" % {'such': "something"}) to make the substitutions less fragile and, presumably, easier to debug. - Removed hardwired (and failure-prone) /tmp file logging from answer.majordomo_mail, and generally spiffed up following janne sinkkonen's lead. 1.0b2 (04/13/1998) and 1.0b1.1 (04/09/1998): klm (ken manheimer) Web pages much more polished - Better organized, text more finely crafted - Easier, more refined layout - List info and admin interface overviews, enumerate all public lists (via, e.g., http://www.python.org/mailman/listinfo - sans the specific list) - Admin interface broken into sections, with help elaboration for complicated configuration options Maillist Archives - Integrated with a newer, *much* improved, external pipermail - to be found at http://starship.skyport.net/crew/amk/maintained/pipermail.html - Private archives protected with maillist members passwords, cookie-fied. Spam prevention - New spam prevention measures catch most if not all spam without operator intervention or general constraints on who can post to list: require_explicit_destination option imposes hold of any postings that do not have the list name in any of the to or cc header destination addresses. This catches the vast majority of random spam. Other options (forbidden_posters, bounce_matching_headers) provide for filtering of known transgressors. - Option obscure_addresses (default on) causes maillist subscriber lists on the web to be slightly mangled so they're not directly recognizable as email address by web spiders, which might be seeking targets for spammers. Site configuration arrangement organized - in mailman/mailman/modules: - When installing, create a mailman/modules/mm_cfg.py (if there's not one already there), using mm_cfg.py.dist as a template. mm_default.py contains the distributed defaults, including descriptions of the values. mm_cfg.py does a 'from mm_defaults.py import *' to get the distributed defaults. Include settings in mm_cfg.py for any values in mm_defaults.py that need to be customized for your site, after the 'from .. import *'. See mm_cfg.py.dist for more details. Logging - Major operations (subscription, admin approval, bounce, digestification, cgi script failure tracebacks) logged in files using a reliable mechanism - Wrapper executables log authentication complaints via syslog Wrappers - All cgi-script wrapper executables combined in a single source, easier to configure. (Mail and aliases wrappers separate.) List structure version migration - Provision for automatic update of list structures when moving to a new version of the system. See modules/versions.py. Code cleaning - Many more module docstrings, __version__ settings, more function docstrings. - Most unqualified exception catches have been replaced with more finely targeted catches, to avoid concealing bugs. - Lotsa long lines wrapped (pet peeve:). Random details (not complete, sorry): - make archival frequency a list option - Option for daily digest dispatch, in addition to size threshhold - make sure users only get one periodic password notifcation message for all the lists they're on (repaired 1.0b1.1 varying-case mistake) - Fix rmlist sans-argument bug causing deletion of all lists! - doubled generated random passwords to four letters - Cleaned lots and lots of notices - Lots and lots of html page cleanup, including table-of-contents, etc - Admin options sections - don't do the "if so" if the ensuing list is empty - Prevent list subject-prefix cascade - Sources under CVS - Various spam filters - implicit-destination, header-field - Adjusted permissions for group access - Prevent redundant subscription from redundant vetted requests - Instituted centralize, robustish logging - Wrapper sources use syslog for logging (john viega) - Sorting of users done on presentation, not in list. - Edit options - give an error for non-existent users, not an options page. - Bounce handling - offer 'disable' option, instead of remove, and never remove without notifying admin - Moved subscribers off of listinfo (and made private lists visible modulo authentication) - Parameterize default digest headers and footers and create some - Put titles on cgi result pages that do not get titles (all?) - Option for immediate admin notifcation via email of pending requests, as well as periodic - Admin options web-page help - Enabled grouped and cascading lists despite implicit-name constraint - Changed subscribers list so it has its own script (roster) - Welcome pages: http://www.python.org/mailman/{admin,listinfo}/ 0.95: (Jan 25, 1997) - Fixed a bug in sending out digests added when adding disable mime option. - Added an option to not notify about bounced posts. - Added hook for pre-posting filters. These could be used to auto-strip signatures. I'm using the feature to auto-strip footers that are auto-generated by mail received from another mailing list. 0.94: (Jan 22, 1997) - Made admin password work ubiquitously in place of a user password. - Added an interface for getting / setting user options. - Added user option to disable mime digests (digested people only) - Added user option to not receive your own posts (nondigested people only) - Added user option to ack posts - Added user option to disable list delivery to their box. - Added web interface to user options - Config number of sendmail spawns on a per-list basis - Fixed extra space at beginning of each message in digests... - Handled comma separated emails in bounce messages... - Added a FindUser() function to MailList. Used it where appropriate. - Added mail interface to setting list options. - Added name links to the templates options page - Added an option so people can hide their names from the subscription list. - Added an answer_majordomo_mail script for people switching... 0.93: (Jan 18,20 1997) - When delivering to list, don't call sendmail directly. Write to a file, and then run the new deliver script, which forks and exits in the parent immediately to avoid hanging when delivering mail for large lists, so that large lists don't spend a lot of time locked. - GetSender() no longer assumes that you don't have an owner-xxx address. - Fixed unsubscribing via mail. - Made subscribe via mail generate a password if you don't supply one. - Added an option to clobber the date in the archives to the date the list resent the post, so that the archive doesn't get mail from people sending bad dates clumped up at the beginning or end. - Added automatic error message processing as an option. Currently logging to /tmp/bounce.log - Changed archive to take a list as an argument, (the old way was broken) - Remove (ignore) spaces in email addresses - Allow user passwords to be case insensitive. - Removed the cleanup script since it was now redundant. - Fixed archives if there were no archives. - Added a Lock() call to Load() and Create(). This fixes the problem of loading then locking. - Removed all occurances of Lock() except for the ones in maillist since creating a list now implicitly locks it. - Quote single periods in message text. - Made bounce system handle digest users fairly. 0.92: (Jan 13-16 1997) - Added Lock and Unlock methods to list to ensure each operation is atomic - Added a cmd that rms all files of a mailing list (but not the aliases) - Fixed subscribing an unknown user@localhost (confirm this) - Changed the sender to list-admin@... to ensure we avoid mail loops. - check to make sure there are msgs to archive before calling pipermail. - started using this w/ real mailing lists. - Added a cron script that scours the maillog for User/Host unknown errs - Sort membership lists - Always display digest_is_default option - Don't slam the TO list unless you're sending a digest. - When making digest summaries, if missing sender name, use their email. - Hacked in some protection against crappy dates in pipermail.py - Made it so archive/digest volumes can go up monthly for large large lists. - Number digest messages - Add headers/footers to each message in digest for braindead mailers - I removed some forgotten debug statements that caused server errors when a CGI script sent mail. - Removed loose_matches flag, since everything used it. - Fixed a problem in pipermail if there was no From line. - In upvolume_ scripts, remove INDEX files as we leave a volume. - Threw a couple of scripts in bin for generating archives from majordomo's digest-archives. I wouldn't recommend them for the layman, though, they were meant to do a job quickly, not to be usable. 0.91: (Dec 23 1996) - broke code into mixins for managability - tag parsing instead of lots of gsubs - tweaked pipermail (see comments on pipermail header) - templates are now on a per-list basis as intended. - request over web that your password be emailed to you. - option so that web subscriptions require email confirmation. - wrote a first pass at an admin interface to configurable variables. - made digests mime-compliant. - added a FakeFile class that simulates enough of a file object on a string of text to fool rfc822.Message in non-seek mode. - changed OutgoingMessage not to require its args in constructor. - added an admin request DB interface. - clearly separated the internal name from the real name. - replaced lots of ugly, redundant code w/ nice code. (added Get...Email() interfaces, GetScriptURL, etc...) - Wrote a lot of pretty html formatting functions / classes. (Dec 27 1997) - Fleshed out the newlist command a lot. It now mails the new list admin, and auto-updates the aliases file. - Made multiple owners acceptable. - Non-advertised lists, closed lists, max header length, max msg length - Allowed editing templates from list admin pages. - You can get to your info page from the web even if the list is closed. Please be sure to read the README file after downloading. John Viega From cklempay@acm.jhu.edu Wed Jul 29 14:37:25 1998 From: cklempay@acm.jhu.edu (Corbett J. Klempay) Date: Wed, 29 Jul 1998 09:37:25 -0400 (EDT) Subject: [Mailman-Developers] mmsitepass puking Message-ID: I just upgraded a 1.0b4 --> 1.0b5...when I tried to run mmsitepass (didn't know if I needed to do this again since I was upgrading, but figured it would be better to be safe than sorry...)...and I got this: [root@chimera bin]# mmsitepass snoop Traceback (innermost last): File "./mmsitepass", line 27, in ? from Mailman import MailList File "/home/mailman/Mailman/MailList.py", line 40, in ? from SecurityManager import SecurityManager File "/home/mailman/Mailman/SecurityManager.py", line 24, in ? import Crypt File "/home/mailman/Mailman/Crypt.py", line 19, in ? if mm_cfg.USE_CRYPT: AttributeError: USE_CRYPT [root@chimera bin]# Then, when I tried to look at www2.acm.jhu.edu/mailman/listinfo, I got an internal server error, with this in /var/log/httpd/error_log: [Wed Jul 29 09:27:04 1998] access to /home/mailman/cgi-bin/listinfo failed for 1 28.220.223.50, reason: Premature end of script headers ...and while I was writing this message, I postponed it to investigate something else...I'm now getting this message every 5 minutes from the Cron Daemon: Traceback (innermost last): File "/home/mailman/cron/gate_news", line 22, in ? from Mailman import MailList File "/home/mailman/Mailman/MailList.py", line 40, in ? from SecurityManager import SecurityManager File "/home/mailman/Mailman/SecurityManager.py", line 24, in ? import Crypt File "/home/mailman/Mailman/Crypt.py", line 19, in ? if mm_cfg.USE_CRYPT: AttributeError: USE_CRYPT I tried sending a test message to one of the lists I host..haven't seen it yet (10 minutes ago, so I'm assuming it's not coming). BTW - Kudos to whoever added in the permissions checking in configure! ------------------------------------------------------------------------------- Corbett J. Klempay Quote of the Week: http://www2.acm.jhu.edu/~cklempay "Talent develops in quiet places, character in the full current of human life." PGP Fingerprint: 7DA2 DB6E 7F5E 8973 A8E7 347B 2429 7728 76C2 BEA1 ------------------------------------------------------------------------------- From John@list.org Wed Jul 29 14:31:48 1998 From: John@list.org (John Viega) Date: Wed, 29 Jul 1998 06:31:48 -0700 Subject: [Mailman-Developers] mmsitepass puking In-Reply-To: ; from Corbett J. Klempay on Wed, Jul 29, 1998 at 09:37:25AM -0400 References: Message-ID: <19980729063148.A29993@viega.org> Oh, hmm. We really need to be tracking new variables in the config file. Just throw USE_CRYPT=1 into your mm_cfg.py. Then, if you're interested, diff your old defaults with the one that comes w/ the b5 dist and let us know what else is missing. John On Wed, Jul 29, 1998 at 09:37:25AM -0400, Corbett J. Klempay wrote: > I just upgraded a 1.0b4 --> 1.0b5...when I tried to run mmsitepass (didn't > know if I needed to do this again since I was upgrading, but figured it > would be better to be safe than sorry...)...and I got this: > > [root@chimera bin]# mmsitepass snoop > Traceback (innermost last): > File "./mmsitepass", line 27, in ? > from Mailman import MailList > File "/home/mailman/Mailman/MailList.py", line 40, in ? > from SecurityManager import SecurityManager > File "/home/mailman/Mailman/SecurityManager.py", line 24, in ? > import Crypt > File "/home/mailman/Mailman/Crypt.py", line 19, in ? > if mm_cfg.USE_CRYPT: > AttributeError: USE_CRYPT > [root@chimera bin]# > > Then, when I tried to look at www2.acm.jhu.edu/mailman/listinfo, I got an > internal server error, with this in /var/log/httpd/error_log: > > [Wed Jul 29 09:27:04 1998] access to /home/mailman/cgi-bin/listinfo failed > for 1 > 28.220.223.50, reason: Premature end of script headers > > ..and while I was writing this message, I postponed it to investigate > something else...I'm now getting this message every 5 minutes from the > Cron Daemon: > > Traceback (innermost last): > File "/home/mailman/cron/gate_news", line 22, in ? > from Mailman import MailList > File "/home/mailman/Mailman/MailList.py", line 40, in ? > from SecurityManager import SecurityManager > File "/home/mailman/Mailman/SecurityManager.py", line 24, in ? > import Crypt > File "/home/mailman/Mailman/Crypt.py", line 19, in ? > if mm_cfg.USE_CRYPT: > AttributeError: USE_CRYPT > > I tried sending a test message to one of the lists I host..haven't seen it > yet (10 minutes ago, so I'm assuming it's not coming). > > BTW - Kudos to whoever added in the permissions checking in configure! > > ------------------------------------------------------------------------------- > Corbett J. Klempay Quote of the Week: > http://www2.acm.jhu.edu/~cklempay "Talent develops in quiet places, > character in the full current of > human life." > > PGP Fingerprint: 7DA2 DB6E 7F5E 8973 A8E7 347B 2429 7728 76C2 BEA1 > ------------------------------------------------------------------------------- > > > > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers From cklempay@acm.jhu.edu Wed Jul 29 14:58:50 1998 From: cklempay@acm.jhu.edu (Corbett J. Klempay) Date: Wed, 29 Jul 1998 09:58:50 -0400 (EDT) Subject: [Mailman-Developers] more stuff, it seems... Message-ID: I made the USE_CRYPT = 1 change...and now the 5 minute cron gives me: Date: Wed, 29 Jul 1998 09:55:02 -0400 From: Cron Daemon To: mailman@chimera.acm.jhu.edu Subject: Cron /usr/bin/python /home/mailman/cron/gate_news Traceback (innermost last): File "/home/mailman/cron/gate_news", line 45, in ? list = MailList.MailList(name, lock=0) File "/home/mailman/Mailman/MailList.py", line 60, in __init__ self.Load() File "/home/mailman/Mailman/MailList.py", line 587, in Load self.CheckVersion(dict) File "/home/mailman/Mailman/MailList.py", line 602, in CheckVersion if (self.data_version >= mm_cfg.DATA_FILE_VERSION and AttributeError: DATA_FILE_VERSION Traceback (innermost last): File "/home/mailman/cron/gate_news", line 45, in ? list = MailList.MailList(name, lock=0) File "/home/mailman/Mailman/MailList.py", line 60, in __init__ self.Load() File "/home/mailman/Mailman/MailList.py", line 587, in Load self.CheckVersion(dict) File "/home/mailman/Mailman/MailList.py", line 602, in CheckVersion if (self.data_version >= mm_cfg.DATA_FILE_VERSION and AttributeError: DATA_FILE_VERSION Traceback (innermost last): File "/home/mailman/cron/gate_news", line 45, in ? list = MailList.MailList(name, lock=0) File "/home/mailman/Mailman/MailList.py", line 60, in __init__ self.Load() File "/home/mailman/Mailman/MailList.py", line 587, in Load Traceback (innermost last): File "/home/mailman/cron/gate_news", line 45, in ? list = MailList.MailList(name, lock=0) File "/home/mailman/Mailman/MailList.py", line 60, in __init__ self.Load() File "/home/mailman/Mailman/MailList.py", line 587, in Load self.CheckVersion(dict) File "/home/mailman/Mailman/MailList.py", line 602, in CheckVersion if (self.data_version >= mm_cfg.DATA_FILE_VERSION and AttributeError: DATA_FILE_VERSION self.CheckVersion(dict) File "/home/mailman/Mailman/MailList.py", line 602, in CheckVersion if (self.data_version >= mm_cfg.DATA_FILE_VERSION and AttributeError: DATA_FILE_VERSION John: I have zero diff experience...if you gave me a command line or something, I'd run it (or whatever else) for ya if you need...I just don't want to horse around with it for a long time when a) I'm not sure if I'd be using it right and b) I'm at my new internship and am sneaking out through the corporate firewall to get here :) ------------------------------------------------------------------------------- Corbett J. Klempay Quote of the Week: http://www2.acm.jhu.edu/~cklempay "Talent develops in quiet places, character in the full current of human life." PGP Fingerprint: 7DA2 DB6E 7F5E 8973 A8E7 347B 2429 7728 76C2 BEA1 ------------------------------------------------------------------------------- From John@list.org Wed Jul 29 14:56:25 1998 From: John@list.org (John Viega) Date: Wed, 29 Jul 1998 06:56:25 -0700 Subject: [Mailman-Developers] more stuff, it seems... In-Reply-To: ; from Corbett J. Klempay on Wed, Jul 29, 1998 at 09:58:50AM -0400 References: Message-ID: <19980729065625.A30183@viega.org> Try: diff ~//Defaults.py.in mm_defaults.py (Wasn't it mm_defaults in B4? Whatever your current default file is.) It'll show all differences, including ones where the option is in both files, but just changed. For things other than USE_CRYPT, I suggest just copying the missing items over. Please let us know what they are... John On Wed, Jul 29, 1998 at 09:58:50AM -0400, Corbett J. Klempay wrote: > I made the USE_CRYPT = 1 change...and now the 5 minute cron gives me: > > Date: Wed, 29 Jul 1998 09:55:02 -0400 > From: Cron Daemon > To: mailman@chimera.acm.jhu.edu > Subject: Cron /usr/bin/python > /home/mailman/cron/gate_news > > Traceback (innermost last): > File "/home/mailman/cron/gate_news", line 45, in ? > list = MailList.MailList(name, lock=0) > File "/home/mailman/Mailman/MailList.py", line 60, in __init__ > self.Load() > File "/home/mailman/Mailman/MailList.py", line 587, in Load > self.CheckVersion(dict) > File "/home/mailman/Mailman/MailList.py", line 602, in CheckVersion > if (self.data_version >= mm_cfg.DATA_FILE_VERSION and > AttributeError: DATA_FILE_VERSION > Traceback (innermost last): > File "/home/mailman/cron/gate_news", line 45, in ? > list = MailList.MailList(name, lock=0) > File "/home/mailman/Mailman/MailList.py", line 60, in __init__ > self.Load() > File "/home/mailman/Mailman/MailList.py", line 587, in Load > self.CheckVersion(dict) > File "/home/mailman/Mailman/MailList.py", line 602, in CheckVersion > if (self.data_version >= mm_cfg.DATA_FILE_VERSION and > AttributeError: DATA_FILE_VERSION > Traceback (innermost last): > File "/home/mailman/cron/gate_news", line 45, in ? > list = MailList.MailList(name, lock=0) > File "/home/mailman/Mailman/MailList.py", line 60, in __init__ > self.Load() > File "/home/mailman/Mailman/MailList.py", line 587, in Load > Traceback (innermost last): > File "/home/mailman/cron/gate_news", line 45, in ? > list = MailList.MailList(name, lock=0) > File "/home/mailman/Mailman/MailList.py", line 60, in __init__ > self.Load() > File "/home/mailman/Mailman/MailList.py", line 587, in Load > self.CheckVersion(dict) > File "/home/mailman/Mailman/MailList.py", line 602, in CheckVersion > if (self.data_version >= mm_cfg.DATA_FILE_VERSION and > AttributeError: DATA_FILE_VERSION > self.CheckVersion(dict) > File "/home/mailman/Mailman/MailList.py", line 602, in CheckVersion > if (self.data_version >= mm_cfg.DATA_FILE_VERSION and > AttributeError: DATA_FILE_VERSION > > John: I have zero diff experience...if you gave me a command line or > something, I'd run it (or whatever else) for ya if you need...I just don't > want to horse around with it for a long time when a) I'm not sure if I'd > be using it right and b) I'm at my new internship and am sneaking out > through the corporate firewall to get here :) > > ------------------------------------------------------------------------------- > Corbett J. Klempay Quote of the Week: > http://www2.acm.jhu.edu/~cklempay "Talent develops in quiet places, > character in the full current of > human life." > > PGP Fingerprint: 7DA2 DB6E 7F5E 8973 A8E7 347B 2429 7728 76C2 BEA1 > ------------------------------------------------------------------------------- > > > > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers From cklempay@acm.jhu.edu Wed Jul 29 15:12:08 1998 From: cklempay@acm.jhu.edu (Corbett J. Klempay) Date: Wed, 29 Jul 1998 10:12:08 -0400 (EDT) Subject: [Mailman-Developers] The diffs Message-ID: Here's what diff spit out when I did: diff Defaults.py mm_defaults.py ---- 19c19 < """Distributed default settings for significant Mailman config variables. --- > """Distributed default settings for significant mailman config variables. 47,52d46 < # 1 to use crypt for passwords instead of md5. < # Crypt may not work on all python installs. < # Don't change this value once you have lists running... < # In fact, you should just let configure set this one and leave it alone. < USE_CRYPT = 1 < 86,92d79 < # This variable controlls whether monthly password reminders are sent. < DEFAULT_SEND_REMINDERS = 1 < # Send welcome messages to new users? Probably should keep this set to 1. < DEFAULT_SEND_WELCOME_MSG = 1 < # Wipe sender information, and make it look like the list-admin < # address sends all messages < DEFAULT_ANONYMOUS_LIST = 0 128,130c115,122 < DEFAULT_PLAIN_DIGEST_KEEP_HEADERS = ['message', 'date', 'from', < 'subject', 'to', 'cc', < 'reply-to', 'organization'] --- > # We're only retaining the text file, an external pipermail (andrew's > # newest version) is pointed at the retained text copies. > ## # 0 = never, 1 = daily, 2 = hourly: > ## DEFAULT_ARCHIVE_UPDATE_FREQUENCY = 2 > ## # 0 = yearly, 1 = monthly > ## DEFAULT_ARCHIVE_VOLUME_FREQUENCY = 0 > ## # Retain a flat text mailbox of postings as well as the fancy archives? > ## DEFAULT_ARCHIVE_RETAIN_TEXT_COPY = 1 152a145,165 > # Enumeration for types of configurable variables in Mailman. > Toggle = 1 > Radio = 2 > String = 3 > Text = 4 > Email = 5 > EmailList = 6 > Host = 7 > Number = 8 > > # could add Directory and URL > > > # Bitfield for user options > Digests = 0 # handled by other mechanism, doesn't need a flag. > DisableDelivery = 1 > DontReceiveOwnPosts = 2 # Non-digesters only > AcknowlegePosts = 4 > DisableMime = 8 # Digesters only > ConcealSubscription = 16 > 170c183 < PYTHON = '/usr/local/bin/python' --- > PYTHON = '/usr/bin/python' 178,202d190 < # Don't change anything from here down unless you know what you're doing... < < < # Enumeration for types of configurable variables in Mailman. < Toggle = 1 < Radio = 2 < String = 3 < Text = 4 < Email = 5 < EmailList = 6 < Host = 7 < Number = 8 < < # could add Directory and URL < < < # Bitfield for user options < Digests = 0 # handled by other mechanism, doesn't need a flag. < DisableDelivery = 1 < DontReceiveOwnPosts = 2 # Non-digesters only < AcknowlegePosts = 4 < DisableMime = 8 # Digesters only < ConcealSubscription = 16 < < 216,219c204 < VERSION = '1.0b5' < < # Data file version number < DATA_FILE_VERSION = 3 --- > VERSION = '1.0b4' --- ------------------------------------------------------------------------------- Corbett J. Klempay Quote of the Week: http://www2.acm.jhu.edu/~cklempay "Talent develops in quiet places, character in the full current of human life." PGP Fingerprint: 7DA2 DB6E 7F5E 8973 A8E7 347B 2429 7728 76C2 BEA1 ------------------------------------------------------------------------------- From John@list.org Wed Jul 29 15:09:20 1998 From: John@list.org (John Viega) Date: Wed, 29 Jul 1998 07:09:20 -0700 Subject: [Mailman-Developers] The diffs In-Reply-To: ; from Corbett J. Klempay on Wed, Jul 29, 1998 at 10:12:08AM -0400 References: Message-ID: <19980729070920.C30183@viega.org> On Wed, Jul 29, 1998 at 10:12:08AM -0400, Corbett J. Klempay wrote: Add the following stuff: # This variable controlls whether monthly password reminders are sent. DEFAULT_SEND_REMINDERS = 1 # Send welcome messages to new users? Probably should keep this set to 1. DEFAULT_SEND_WELCOME_MSG = 1 # Wipe sender information, and make it look like the list-admin # address sends all messages DEFAULT_ANONYMOUS_LIST = 0 DEFAULT_PLAIN_DIGEST_KEEP_HEADERS = ['message', 'date', 'from', 'subject', 'to', 'cc', 'reply-to', 'organization'] # Data file version number DATA_FILE_VERSION = 3 From John@list.org Wed Jul 29 15:20:19 1998 From: John@list.org (John Viega) Date: Wed, 29 Jul 1998 07:20:19 -0700 Subject: [Mailman-Developers] The diffs In-Reply-To: ; from Corbett J. Klempay on Wed, Jul 29, 1998 at 10:12:08AM -0400 References: Message-ID: <19980729072019.D30183@viega.org> I realized that the real problem is the name change. Just change the import in mm_cfg.py to Defaults from mm_defaults, and that should have the same effect as adding those lines. John From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Wed Jul 29 15:44:45 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 29 Jul 1998 10:44:45 -0400 (EDT) Subject: [Mailman-Developers] The diffs References: <19980729072019.D30183@viega.org> Message-ID: <13759.13661.65610.200383@anthem.cnri.reston.va.us> >>>>> "JV" == John Viega writes: JV> I realized that the real problem is the name change. Just JV> change the import in mm_cfg.py to Defaults from mm_defaults, JV> and that should have the same effect as adding those lines. Right, dang. We should have included that in the release notes. John, do you think you can start a 1.0b5 release note/patch page off of list.org? -Barry From cklempay@acm.jhu.edu Wed Jul 29 16:04:53 1998 From: cklempay@acm.jhu.edu (Corbett J. Klempay) Date: Wed, 29 Jul 1998 11:04:53 -0400 (EDT) Subject: [Mailman-Developers] Oddities Message-ID: Well, I left those settings in mm_cfy.py that I copied in, and ended up also changing the import to have it import from Defaults.py (so I guess that's redundant, but it shouldn't hurt anything, eh?). Anyway, the annoying 5 minute cron messages have stopped...so I guess that part is kosher now. However two problems remain: - Test messages sent to one of the lists from my previous 1.0b4 install are just getting swallowed up and never getting sent to the list - Going to www2.acm.jhu.edu/mailman/listinfo still gives an Internal Server Error...and the /var/log/httpd/error_log file lists this at the end: [Wed Jul 29 10:43:32 1998] access to /home/mailman/cgi-bin/listinfo failed for 1 28.220.223.50, reason: Premature end of script headers Any ideas? ------------------------------------------------------------------------------- Corbett J. Klempay Quote of the Week: http://www2.acm.jhu.edu/~cklempay "Talent develops in quiet places, character in the full current of human life." PGP Fingerprint: 7DA2 DB6E 7F5E 8973 A8E7 347B 2429 7728 76C2 BEA1 ------------------------------------------------------------------------------- From cklempay@acm.jhu.edu Wed Jul 29 16:08:19 1998 From: cklempay@acm.jhu.edu (Corbett J. Klempay) Date: Wed, 29 Jul 1998 11:08:19 -0400 (EDT) Subject: [Mailman-Developers] hehe...typo Message-ID: Just to clear any confusion, I of course meant mm_cfg.py in that first line of the last message... :) ------------------------------------------------------------------------------- Corbett J. Klempay Quote of the Week: http://www2.acm.jhu.edu/~cklempay "Talent develops in quiet places, character in the full current of human life." PGP Fingerprint: 7DA2 DB6E 7F5E 8973 A8E7 347B 2429 7728 76C2 BEA1 ------------------------------------------------------------------------------- From cklempay@acm.jhu.edu Thu Jul 30 17:50:23 1998 From: cklempay@acm.jhu.edu (Corbett J. Klempay) Date: Thu, 30 Jul 1998 12:50:23 -0400 (EDT) Subject: [Mailman-Developers] Anyone else seeing this? Message-ID: Ok, this is really 2 messages chained together...it seems John is soon to be a dad (or maybe a dad again, not sure actually :), so he's a little busy :) Any assistance is _greatly_ appreciated...the other ACM guys kept whining because the list is down, so I just set up a temp alias to quiet them until I get this sorted out :) --- Is it supposed to be the case where you have to be root to create a new list? I thought that in my 1.0b4 install, I had created new lists as cklempay...but if I do it as anything other than root now (with b5), I get this: [mailman@chimera bin]$ newlist test Enter the email of the person running the list: cklempay@acm.jhu.edu Enter the initial list password: snoop Traceback (innermost last): File "/home/mailman/bin/newlist", line 133, in ? raise SystemExit(main(sys.argv)) File "/home/mailman/bin/newlist", line 83, in main newlist.Create(list_name, owner_mail, pw) File "/home/mailman/Mailman/MailList.py", line 518, in Create Utils.MakeDirTree(os.path.join(mm_cfg.LIST_DATA_DIR, name)) File "/home/mailman/Mailman/Utils.py", line 276, in MakeDirTree os.mkdir(made_part, perms) os.error: (13, 'Permission denied') [mailman@chimera bin]$ I don't know if this is the way it is supposed to be and maybe I had it working before only because maybe I had messed up some permissions... I had been having a LOT of problems getting it to let me access any of the pages (all of the logs turned up 'Premature end of script headers' or in some configurations I'd get a Internal Server Error). In my current state, I can view www2.acm.jhu.edu/mailman/listinfo but if I su to root and do a newlist to create a test list, I get this if I try to access www2.acm.jhu.edu/mailman/admin/test : 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: Content-type: text/html We're sorry, we hit a bug! Mailman experienced a very low level failure and could not even generate a useful traceback. Please report this to the Mailman administrator at this site. I'm not sure, but I thought I remembered someone mentioning something like this earlier today too. One other quick (and sort of unrelated question)...I just recursively zipped up my /home/mailman/lists subtree before killing b4...since my aliases are still in place (didn't touch those), can I just extract them to their original places and have it work? Or does Mailman keep other administrative data about that it won't have for these lists if I create them that way? ---next msg---- From CorbettJ.Klempay Thu Jul 30 17:04:20 1998 From: CorbettJ.Klempay (CorbettJ.Klempay) Date: Thu, 30 Jul 1998 12:04:20 -0400 (EDT) Subject: Cron /usr/bin/python /home/mailman/cron/senddigests (fwd) I am getting this as well...I followed the permissions stuff to the letter...? ---------- Forwarded message ---------- Date: Thu, 30 Jul 1998 12:00:00 -0400 From: Cron Daemon To: mailman@chimera.acm.jhu.edu Subject: Cron /usr/bin/python /home/mailman/cron/senddigests Traceback (innermost last): File "/home/mailman/cron/senddigests", line 37, in ? main() File "/home/mailman/cron/senddigests", line 31, in main list = MailList.MailList(name, lock=0) File "/home/mailman/Mailman/MailList.py", line 60, in __init__ self.Load() File "/home/mailman/Mailman/MailList.py", line 587, in Load self.CheckVersion(dict) File "/home/mailman/Mailman/MailList.py", line 611, in CheckVersion self.Save() File "/home/mailman/Mailman/MailList.py", line 558, in Save os.link(fname, fname_last) os.error: (13, 'Permission denied') ---end #2 ------------------------------------------------------------------------------- Corbett J. Klempay Quote of the Week: http://www2.acm.jhu.edu/~cklempay "Talent develops in quiet places, character in the full current of human life." PGP Fingerprint: 7DA2 DB6E 7F5E 8973 A8E7 347B 2429 7728 76C2 BEA1 ------------------------------------------------------------------------------- From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Thu Jul 30 19:59:40 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 30 Jul 1998 14:59:40 -0400 (EDT) Subject: [Mailman-Developers] Anyone else seeing this? References: Message-ID: <13760.49820.31602.245524@anthem.cnri.reston.va.us> Corbett, I suspect all your problems are related to permission or ownership problems. You installed 1.0b5 on top of an earlier installation didn't you? Earlier versions weren't quite as strict on perm/ownership (esp. group ownership) as 1.0b5 -- but they had other problems. BTW, you followed the README note about moving your list template files right? Please look at your installed directory (e.g. $prefix). You want to make sure all the files are group owned by the `mailman' group, and that all directories and files are writeable by group. Further, be sure that all directories have the group sticky bit set (so new files will inherit the right group owner). You want to in particular, make sure lists/yourlist/config.db is group writeable, etc. If all that looks okay, but still doesn't work, then I might suggest trying to re-install Mailman 1.0b5 into a fresh location. Re-run configure with a different --prefix. Once you've done the new install, try creating a test list under the new location (you might need to set up your Web server to include a second ScriptAlias). If this test list works, then you should be able to copy your existing list subdirs to the new location (again, watching very carefully group write permission and ownership). Now your old lists should work from your new URLs. -Barry From cklempay@acm.jhu.edu Thu Jul 30 20:27:56 1998 From: cklempay@acm.jhu.edu (Corbett J. Klempay) Date: Thu, 30 Jul 1998 15:27:56 -0400 (EDT) Subject: [Mailman-Developers] Anyone else seeing this? In-Reply-To: <13760.49820.31602.245524@anthem.cnri.reston.va.us> Message-ID: > > Corbett, > > I suspect all your problems are related to permission or ownership > problems. You installed 1.0b5 on top of an earlier installation > didn't you? Earlier versions weren't quite as strict on > perm/ownership (esp. group ownership) as 1.0b5 -- but they had > other problems. BTW, you followed the README note about moving your > list template files right? > Yeah, I thought that the install over was maybe causing me some headaches...so I did a nice rm -rf on my mailman dir and killed the user, and started over from scratch. All of the reported problems (from the previous posting) were encountered from this clean 1.0b5 install. > Please look at your installed directory (e.g. $prefix). You want to > make sure all the files are group owned by the `mailman' group, and > that all directories and files are writeable by group. Further, be > sure that all directories have the group sticky bit set (so new files > will inherit the right group owner). Yeah, they appeared to be...and to make sure, I just went to /home and did chmod -R g+w mailman chmod -R g+s mailman After doing this, I pointed Netscape at http://www2.acm.jhu.edu/mailman/listinfo (as well as www2.acm.jhu.edu/mailman/listinfo/test -- I created this list as per the install)...and both gave me this now-familiar page: 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: Content-type: text/html We're sorry, we hit a bug! Mailman experienced a very low level failure and could not even generate a useful traceback. Please report this to the Mailman administrator at this site. > > You want to in particular, make sure lists/yourlist/config.db is group > writeable, etc. > I killed my b4 install, but before I did, I recursively zipped up my lists subtree. So are you saying that as long as the permissions on them are right, I can just unzip them back to their place and my old lists will live once again? (all of the aliases are still active from them) I haven't tried this yet...(as I was trying to sort of these regular problems first) Just in case you spot anything odd, I'm going to send my ls -l -R /home/mailman your way (just to you...don't want to spam the list with that...) CK From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Thu Jul 30 21:24:51 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 30 Jul 1998 16:24:51 -0400 (EDT) Subject: [Mailman-Developers] Anyone else seeing this? References: <13760.49820.31602.245524@anthem.cnri.reston.va.us> Message-ID: <13760.54931.368574.994944@anthem.cnri.reston.va.us> --M7zH6CPYdt Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Corbett, Everything looks okay to me, and I just did a fresh install, as root, from the 1.0b5 tarball. Then I created a dummy list and had no problem viewing the list-of-lists and the specific list info page. Note that I am running this in a Solaris 2.6 system, what OS are you using? We've had one other report of something similar happening on Linux (so I wonder if some OS problem could happening). Since I can't reproduce the problem on my end, I'm going to need your help. We have trace through the driver script to see where it's crapping out. Here's a version that does some very simple print-style tracing to /tmp/mailman.log. Can you substitute this for scripts/driver and see if it gives you a clue as to what is failing? -Barry --M7zH6CPYdt Content-Type: text/plain Content-Description: test driver script Content-Disposition: inline; filename="driver" Content-Transfer-Encoding: 7bit #! /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. # Useful for debugging. When an error occurs, this attaches the file name to # the exception string and re-raises (using the bogus Python 1.5 semantics) # this may be unnecessary in Python 1.5.2 ## realopen = open ## def open(filename, mode='r', bufsize=-1, realopen=realopen): ## try: ## return realopen(filename, mode, bufsize) ## except IOError, e: ## strerror = e.strerror + ': ' + filename ## e.strerror = strerror ## e.args = (e.args[0], strerror) ## # Python 1.5 ## import sys ## raise e, None, sys.exc_info()[2] ## # Python 1.5.1 ## #raise ## import __builtin__ ## __builtin__.__dict__['open'] = open # This standard driver script is used to run CGI programs, wrapped in code # that catches errors, and displays them as HTML. This guarantees that # (almost) any problems in the Mailman software doesn't result in a Web server # error. It is much more helpful to generate and show a traceback, which the # user could send to the administrator, than to display a server error and # have to trudge through server logs. # Note: this isn't 100% perfect! Here are some things that can go wrong that # are not caught and reported as traceback-containing HTML: # # - This file could contain a syntax error. In that case, you would indeed # get a Web server error since this file wouldn't even compile, and there's # no way to catch that. # # - The sys module could be royally screwed. Either we couldn't import it, or # it didn't have a sys.stderr attribute. Both those would indicate serious # problems in the Python installation. These won't generate Web server # errors, but neither will they give meaningful tracebacks. # # - We couldn't import the traceback module, or traceback.print_exc() # failed. Same diagnosis and effect as with sys being broken. # # I consider all these pretty unlikely. Note that it is also possible that # the environment variables wouldn't be printed, perhaps because os couldn't # be imported or there was some problem with os.environ. Again, not likely. def run_main(): try: # insert the relative path to the parent of the Mailman package # directory, so we can pick up the Utils module fp.write('import os\n') import os # sys gets imported at module level below fp.write('sys.path.insert()\n') sys.path.insert(0, os.pardir) # map stderr to a logger, if possible fp.write('import StampedLogger\n') from Mailman.Logging.StampedLogger import StampedLogger fp.write('import MultiLogger\n') from Mailman.Logging.MultiLogger import MultiLogger fp.write('instantiating logger\n') logger = StampedLogger('error', label='admin', manual_reprime=1, nofail=0) fp.write('instantiating multi\n') multi = MultiLogger(sys.__stdout__, logger) # The name of the module to run is passed in argv[1]. What we # actually do is import the module named by argv[1] that lives in the # Mailman.Cgi package. That module must have a main() function, which # we dig out and call. # fp.write('should now get normal error reporting\n') scriptname = sys.argv[1] # See the reference manual for why we have to do things this way. # Note that importing should have no side-effects! pkg = __import__('Mailman.Cgi', globals(), locals(), [scriptname]) module = getattr(pkg, scriptname) main = getattr(module, 'main') try: main() except SystemExit: # this is a valid way for the function to exit pass except: print_traceback(logger, multi) print_environment(logger) def print_traceback(logger, multi): print """\ Content-type: text/html

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:

"""
    logger.write('[----- Traceback ------]\n')
    try:
        import traceback
        # in normal situation, this will get logged to the MultiLogger created
        # above, which will write the data to both the real live stdout, and
        # the StampedLogger
        traceback.print_exc(file=multi)
    except:
        multi.write('[failed to get a traceback]\n')
    print '\n\n
' def print_environment(logger): try: import os print '''\

Environment variables:

''' logger.write('[----- Environment Variables -----]\n') for varname, value in os.environ.items(): print '' logger.write('\t%s: %s\n' % (varname, value)) print '
Variable Value
', varname, '', value, '
' except: print '

[environment variables are not available]' try: fp = open('/tmp/mailman.log', 'w+') fp.write('=====\nimport sys\n') import sys try: fp.write('run_main()\n') run_main() fp.write('done.\n') finally: # this is probably not strictly necessary since the script is exiting # soon anyway sys.stderr = sys.__stderr__ except: # Jeez, we couldn't even import sys, or sys didn't have a stderr # attribute! print """\ Content-type: text/html

We're sorry, we hit a bug!

Mailman experienced a very low level failure and could not even generate a useful traceback. Please report this to the Mailman administrator at this site. """ --M7zH6CPYdt-- From cklempay@acm.jhu.edu Thu Jul 30 22:24:28 1998 From: cklempay@acm.jhu.edu (Corbett J. Klempay) Date: Thu, 30 Jul 1998 17:24:28 -0400 (EDT) Subject: [Mailman-Developers] Anyone else seeing this? In-Reply-To: <13760.54931.368574.994944@anthem.cnri.reston.va.us> Message-ID: Ok, I'll play with that sometime tonight..I have to split now for a few hours. (my TA hours coming up in a bit here) The system is a Red Hat 5.1 system. ------------------------------------------------------------------------------- Corbett J. Klempay Quote of the Week: http://www2.acm.jhu.edu/~cklempay "Talent develops in quiet places, character in the full current of human life." PGP Fingerprint: 7DA2 DB6E 7F5E 8973 A8E7 347B 2429 7728 76C2 BEA1 ------------------------------------------------------------------------------- From cklempay@acm.jhu.edu Fri Jul 31 02:00:09 1998 From: cklempay@acm.jhu.edu (Corbett J. Klempay) Date: Thu, 30 Jul 1998 21:00:09 -0400 (EDT) Subject: [Mailman-Developers] /tmp/mailman.log Message-ID: Barry and the crew: I just put in the new driver a bit ago...and went to www2.acm.jhu.edu/mailman/listinfo /tmp/mailman.log showed up then...this is what it contained: [cklempay@chimera /tmp]$ cat mailman.log ===== import sys run_main() import os sys.path.insert() import StampedLogger import MultiLogger instantiating logger instantiating multi should now get normal error reporting [cklempay@chimera /tmp]$ Corbett From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Fri Jul 31 15:32:11 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 31 Jul 1998 10:32:11 -0400 (EDT) Subject: [Mailman-Developers] /tmp/mailman.log References: Message-ID: <13761.54635.212557.853073@anthem.cnri.reston.va.us> Something truly strange is happening. I don't understand how you can get that far through the driver script and still get a low level error with no traceback. Let me think about it -- I must be missing something. -Barry From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Fri Jul 31 16:25:55 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 31 Jul 1998 11:25:55 -0400 (EDT) Subject: [Mailman-Developers] Potential gotcha Message-ID: <13761.57859.883789.48657@anthem.cnri.reston.va.us> Corbett has been very kind in allowing me access to his machine to debug his problems. Since others have reported similar problems, I want to give you a heads up. Please double check that the programs in /home/mailman/cgi-bin are group owned by `mailman' and have the group sticky bit set. This is imperative; Mailman just won't work without this. I know need to figure out why the install procedure is broken on some systems, and how the driver script can better report and recover from these problems. Thanks Corbett! -Barry From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Fri Jul 31 16:56:35 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 31 Jul 1998 11:56:35 -0400 (EDT) Subject: [Mailman-Developers] Potential gotcha References: <13761.57859.883789.48657@anthem.cnri.reston.va.us> Message-ID: <13761.59699.389393.16655@anthem.cnri.reston.va.us> Me> I know need to figure out why the install procedure is broken Me> on some systems, and how the driver script can better report Me> and recover from these problems. There is a bug in the top-level Makefile.in file which could cause the cgi-bin and mail subdirectories to not have their group sticky bit set. This in turn would cause the CGI binaries to be installed with the wrong group ownership. Please apply the following patch and do a fresh re-install, or make sure that CGI binaries and mail/wrapper are both group'd to mailman and have the g+s bit set (might as well set the bit on the cgi-bin and mail directories too). Sorry about that. -Barry -------------------- snip snip -------------------- Index: Makefile.in =================================================================== RCS file: /projects/cvsroot/mailman/Makefile.in,v retrieving revision 1.5 diff -c -r1.5 Makefile.in *** Makefile.in 1998/07/02 19:35:28 1.5 --- Makefile.in 1998/07/31 15:51:07 *************** *** 88,93 **** --- 88,94 ---- echo "Creating directory hierarchy $$dir"; \ ./mkinstalldirs $$dir; \ chmod $(DIRMODE) $$dir; \ + chmod g+s $$dir; \ else true; \ fi; \ done From Dan@feld.cvut.cz Wed Jul 1 13:40:13 1998 From: Dan@feld.cvut.cz (Dan Ohnesorg, admin on power) Date: Wed, 1 Jul 1998 14:40:13 +0200 Subject: [Mailman-Developers] Some patch for mailman Message-ID: Hi everybody, I am plaing with mailman some time (John probaly remebers me) and now I see, that www.list.org is back online. So what I have, I would suggest You patch to verbose funcionality of mailman. All sugestion to my solution are welcome. What it solves, first part of patch to remove irriting headers from messages. I dont like to send messages like RCPT and so. Second uses DSN to send mails. This disables (when enabled) messages like warning, message is not delivered for 4 hours and so. Then comes some removing of winmail.dat binary attachments. I am working on removing all unwanted parts (html, rtf) and translating national characters into ascii, but is not complete yet. Then comes administrativ via filter, but it not works, it worked on mailman 1.0, but I cannot bring it running on b4, You will see, it is probably only a little bug, at least the filter shields list from administrative messages. So it is all for today, I am interested how You will find this patch, please send any comments to my. cheers dan diff -ru mailman-1.0b4/modules/mm_defaults.py mailman-1.0b4.new/modules/mm_defaults.py --- mailman-1.0b4/modules/mm_defaults.py Fri Jun 26 12:41:28 1998 +++ mailman-1.0b4.new/modules/mm_defaults.py Fri Jun 26 18:43:28 1998 @@ -202,3 +202,11 @@ # The Mailman version, also set by configure VERSION = '1.0b4' + +# Remove Microsoft binary attachments +REMOVE_WINMAIL = 1 +WINMAIL_FILTER_START = 'begin 600 WINMAIL\.DAT' +WINMAIL_FILTER_STOP = 'end' + +# Headers which are not useful +FILTER_HEADERS = ['^X-Confirm-Reading-To:','^X-pmrqc:','X-PMFLAGS:','^Return-receipt-to:'] Only in mailman-1.0b4/modules: mm_defaults.py.in diff -ru mailman-1.0b4/modules/mm_deliver.py mailman-1.0b4.new/modules/mm_deliver.py --- mailman-1.0b4/modules/mm_deliver.py Wed Jun 3 15:12:53 1998 +++ mailman-1.0b4.new/modules/mm_deliver.py Fri Jun 26 18:32:35 1998 @@ -135,6 +135,12 @@ msg.headers.append('To: %s\n' % self.GetListEmail()) else: tempfile.template = tmpfile_prefix + 'mailman.' +# Now remove unwanted headers from message + for pat in mm_defaults.FILTER_HEADERS: + try: + del msg[pat] + except: + pass if self.reply_goes_to_list: del msg['reply-to'] msg.headers.append('Reply-To: %s\n' % self.GetListEmail()) diff -ru mailman-1.0b4/modules/mm_message.py mailman-1.0b4.new/modules/mm_message.py --- mailman-1.0b4/modules/mm_message.py Tue Jun 2 04:47:11 1998 +++ mailman-1.0b4.new/modules/mm_message.py Fri Jun 26 18:01:47 1998 @@ -21,7 +21,7 @@ import sys -import rfc822, string, time +import rfc822, string, time, mm_defaults, regex # Utility functions 2 of these classes use: @@ -134,6 +134,24 @@ if (string.lower(self.headers[i][:len(name)+1]) == string.lower(name) + ':'): self.headers[i] = '%s: %s' % (name, value) + + def RemoveWinmail(self): + pattern_start = regex.compile(mm_defaults.WINMAIL_FILTER_START) + pattern_stop = regex.compile(mm_defaults.WINMAIL_FILTER_STOP) + occured = 0 + mybody=[] + mybody=string.split(self.body,'\n'); + for line in mybody[:]: + if occured == 1: + if pattern_stop.match(line) > 0: + occured = 0 + mybody.remove(line) + elif pattern_start.match(line) > 0: + occured = 1 + mybody.remove(line) + self.body=string.join(mybody,'\n') + + # XXX Eventually (1.5.1?) Python rfc822.Message() will have its own # __delitem__. diff -ru mailman-1.0b4/modules/smtplib.py mailman-1.0b4.new/modules/smtplib.py --- mailman-1.0b4/modules/smtplib.py Sat May 30 05:09:21 1998 +++ mailman-1.0b4.new/modules/smtplib.py Wed Jul 1 14:27:23 1998 @@ -20,6 +20,9 @@ # A lot of functionality was borrowed directly from ftplib... # John Viega (viega@list.org) +# Hack to use DSN, probably not the best way, but works fine +# But I have no not DSN aware server to check it without DSN + # >>> from smtplib import * # >>> s = SmtpConnection('list.org') # >>> s.helo('adder.cs.virginia.edu') @@ -27,7 +30,7 @@ # >>> s.quit() from socket import * -import string, types +import string, types, regex SMTP_PORT = 25 @@ -38,6 +41,8 @@ error_temp = 'smtplib.error_temp' # 4xx errors error_perm = 'smtplib.error_perm' # 5xx errors error_proto = 'smtplib.error_proto' # response does not begin with [1-5] +error_no_DSN = 'There is no DSN support' +DSN_support = 1 class SmtpConnection: def __init__(self, host=''): @@ -52,8 +57,15 @@ self.getresp() def helo(self, host): - self._sock.send('HELO %s\r\n' % host) - self.getresp() + self._sock.send('EHLO %s\r\n' % host) + try: + vysl = self.getresp() + except error_perm: + self._sock.send('HELO %s\r\n' % host) + self.getresp() + self.DSN_support=0 + if regex.match('.*DSN.*',vysl) == -1: + self.DSN_support=0 def quit(self): self._sock.send('QUIT\r\n') @@ -66,12 +78,16 @@ lines = string.split(text, '\n') self._sock.send('MAIL FROM: %s\r\n' % frm) self.getresp() + if DSN_support: + format = 'RCPT TO: %s NOTIFY=failure\r\n' + else: + format = 'RCPT TO: %s\r\n' if type(to) == types.StringType: - self._sock.send('RCPT TO: %s\r\n' % to) + self._sock.send(format % to) self.getresp() else: for item in to: - self._sock.send('RCPT TO: %s\r\n' % item) + self._sock.send(format % item) self.getresp() self._sock.send('DATA\r\n') self.getresp() diff -ru mailman-1.0b4/scripts/post mailman-1.0b4.new/scripts/post --- mailman-1.0b4/scripts/post Sun May 31 06:48:09 1998 +++ mailman-1.0b4.new/scripts/post Fri Jun 26 18:06:57 1998 @@ -31,7 +31,7 @@ import sys import paths -import maillist, mm_message, mm_err, mm_cfg, mm_utils +import maillist, mm_message, mm_err, mm_cfg, mm_utils, string, mm_defaults try: sys.stderr = mm_utils.StampedLogger("error", label = 'post', @@ -42,6 +42,18 @@ # Only let one program run at once per list. # TODO: This can fail, and should send back an error message when it does. +commands = { + 'subscribe' : '', + 'unsubscribe' : '', + 'who' : '', + 'info' : '', + 'lists' : '', + 'help' : '', + 'set' : '', + 'options' : '', + 'password' : '', + } + current_list = maillist.MailList(sys.argv[1]) if len(sys.argv) > 2: current_list.tmp_prevent_gate = 1 @@ -60,10 +72,41 @@ else: text = sys.stdin.read() msg = mm_message.IncomingMessage(text) + if mm_defaults.REMOVE_WINMAIL: msg.RemoveWinmail() + bad_dest = 0 + subject = msg.getheader("subject") + if subject: + subject = string.strip(subject) + if commands.has_key(string.split(subject)[0]): + bad_dest = 1 + lines = string.split(msg.body, '\n') + if len(lines) >= 10: + hopcnt = range(10) + else: + hopcnt = range(len(lines)) + for i in hopcnt: + try: + string.strip(lines[i]) + except: + pass + if not lines[i]: + continue + args = string.split(lines[i]) + if len(args)>0: + cmd = string.lower(args[0]) + if commands.has_key(cmd): + bad_dest = 1 - try: + if bad_dest: + try: + current_list.ParseMailCommands() + finally: +# current_list.Unlock() + pass + else: + try: current_list.Post(msg) - except mm_err.MMNeedApproval, err_msg: + except mm_err.MMNeedApproval, err_msg: if (current_list.dont_respond_to_post_requests or err_msg == mm_err.MODERATED_LIST_MSG or err_msg == mm_err.IMPLICIT_DEST_MSG ________________________________________ DDDDDD DD DD Dan Ohnesorg, supervisor on POWER DD OOOO Dan@feld.cvut.cz DD OODDOO Dep. of Power Engineering DDDDDD OO CVUT FEL Prague, Bohemia OO OO work: +420 2 24352785;+420 2 24972109 OOOO home: +420 311 679679;+420 311 679311 ________________________________________ Pocitac se od televizniho divaka lisi tim, ze ma vlastni program. From gorgo@caesar.elte.hu Thu Jul 2 12:47:18 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Thu, 2 Jul 1998 13:47:18 +0200 (METDST) Subject: [Mailman-Developers] mailpasswds Message-ID: Hello! I have problems with mailpasswds... first it did not work because of this line: url = list.GetOptionsURL(user) I changed it to: url = list.GetAbsoluteOptionsURL(user) Now it starts (the text is a bit misplaced in the mails it sends), but forks too many times (I have two lists, 500 and 120 subscribers): Traceback (innermost last): File "/var/lib/mailman/cron/mailpasswds", line 114, in ? main() File "/var/lib/mailman/cron/mailpasswds", line 111, in main MailAllPasswords(list, users) File "/var/lib/mailman/cron/mailpasswds", line 78, in MailAllPasswords list.SendTextToUser(subject = subj, File "/usr/lib/mailman/Mailman/mm_deliver.py", line 105, in SendTextToUser mm_utils.SendTextToUser(subject, text, recipient, sender, File "/usr/lib/mailman/Mailman/mm_utils.py", line 145, in SendTextToUser DeliverToUser(msg, recipient, add_headers=add_headers) File "/usr/lib/mailman/Mailman/mm_utils.py", line 158, in DeliverToUser if os.fork(): os.error: (11, 'Resource temporarily unavailable') There should be a better way to handle these mails... either to have a better mailing algorithm, or to handle this error, wait for a minute, then continue. Greg -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From klm@python.org Thu Jul 2 22:07:36 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 2 Jul 1998 17:07:36 -0400 (EDT) Subject: [Mailman-Developers] mailpasswds In-Reply-To: References: Message-ID: <13723.62736.17291.209644@glyph.cnri.reston.va.us> --UfXfOrm0J+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gergely Madarasz writes: > I have problems with mailpasswds... first it did not work because of this > line: > url = list.GetOptionsURL(user) > I changed it to: > url = list.GetAbsoluteOptionsURL(user) > Now it starts (the text is a bit misplaced in the mails it sends), but > forks too many times (I have two lists, 500 and 120 subscribers): > [...] > There should be a better way to handle these mails... either to have a > better mailing algorithm, or to handle this error, wait for a minute, then > continue. You don't say which version you're running, but we ran into the same problem here at python.org (yesterday, when the passwords went out), and i've attacked the problem on two fronts in the current code. I'll describe what i did for the first one, if you want to try to reproduce it in your own code, and include a new version of cron/mailpasswds for 1.0b4 for the second. One fix is to change the "os.forks()" in the scripts/deliver script to use the following 'forker()' routine, which recognizes errno.EAGAIN, and retries to fork a specified number of times. (You have to have settings in the module for TRIES and REFRACT - i use 5 and 15, respectively.) TRIES = 5 REFRACT = 15 def forker(tries=TRIES, refract=REFRACT): """Fork, retrying on EGAIN errors with refract secs pause between tries. Returns value of os.fork(), or raises the exception for: (1) non-EAGAIN exception, or (2) EGAIN exception encountered more than tries times.""" got = 0 for i in range(tries): # Loop until we successfully fork or the number tries is exceeded. try: got = os.fork() break except os.error, val: import errno, sys, time if val[0] == errno.EAGAIN: # Resource temporarily unavailable. time.sleep(refract) else: # No go - reraise original exception, same stack frame and all. raise val, None, sys.exc_info()[2] return got Another solution is to have the mailpasswds script take some time to do an os.wait() every several users - i'm attaching a version of cron/mailpasswds for 1.0b4 that does this. --UfXfOrm0J+ Content-Type: text/plain Content-Description: 1.0b4 cron/mailpasswds which periodically waits for forked processes Content-Disposition: inline; filename="mailpasswds" Content-Transfer-Encoding: 7bit #! /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. """Send password reminders for all lists to all users. We accumulate users and their passwords, and use the last list to send a single message to each user with their complete collection of passwords, rather than sending a single message for each password.""" # This puppy should probably do lots of logging. import sys, os, string, time, errno import paths import maillist, mm_cfg, mm_message, mm_utils # Give time for the delivery process-forks to clear every so often, to # avoid saturation of the process table. Set zero or negative for no # pauses. PAUSE_FREQUENCY = 20 USERPASSWORDSTEXT = """ This is a reminder, sent out once a month, about your %s mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. Passwords for %s: %s %s You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, %s-request@%s) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@%s. Thanks! """ def MailAllPasswords(list, users): """Send each user their complete list of passwords. The list can be any random one - it is only used for the message delivery mechanism.""" subj = '%s maillist memberships reminder\n' % list.host_name count = PAUSE_FREQUENCY for user, data in users.items(): table = [] for l, p, u in data: if len(l) > 9: table.append("%s\n %-10s\n%s\n" % (l, p, u)) else: table.append("%-10s %-10s\n%s\n" % (l, p, u)) header = ("%-10s %-10s\n%-10s %-10s" % ("List", "Password // URL", "----", "--------")) text = USERPASSWORDSTEXT % (list.host_name, user, header, string.join(table, "\n"), l, list.host_name, list.host_name) list.SendTextToUser(subject = subj, recipient = user, text = text, sender = mm_cfg.MAILMAN_OWNER, add_headers = ["X-No-Archive: yes"], raw=1) count = count - 1 if count == 0: # The pause that refreshes. waitall() count = PAUSE_FREQUENCY def main(): """Consolidate all the list/url/password info for each user, so we send the user a single message with the info for all their lists on this site.""" list = None users = {} # user: (listname, password, url) for name in mm_utils.list_names(): list = maillist.MailList(name) list_name = list.real_name reminders_to_admins = list.reminders_to_admins for user, password in list.passwords.items(): url = list.GetAbsoluteOptionsURL(user) if reminders_to_admins: recipient = "%s-admin@%s" % tuple(string.split(user, '@')) else: recipient = user if users.has_key(recipient): users[recipient].append(list_name, password, url) else: users[recipient] = [(list_name, password, url)] # Unlocking each list after identifying passwords, but before having # the consolidated list, means that there is a window for discrepancy # between the reported and actual password. Big deal - if the user # changed the password in the meanwhile, they'll realize it, and it's # not worth the extra deadlock risk. list.Unlock() if list: MailAllPasswords(list, users) def waitall(): """Return only when there are no forked subprocesses running.""" try: while 1: os.wait() except os.error, val: if val[0] == errno.ECHILD: # errno.ECHILD: "No child processes" return else: raise val, None, sys.exc_info()[2] if __name__ == "__main__": main() --UfXfOrm0J+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I've done a little testing of both these approaches, but since the problem exists at the resource limit, and entails sending out messages to lots of people, i'm limited in the testing i could do. Caveat emptor! (And "everyone scrutinize" - the more eyes the better.) Ken Manheimer klm@python.org 703 620-8990 x268 (orporation for National Research |nitiatives # If you appreciate Python, consider joining the PSA! # # . # --UfXfOrm0J+-- From gorgo@caesar.elte.hu Sun Jul 5 13:48:12 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Sun, 5 Jul 1998 14:48:12 +0200 (METDST) Subject: [Mailman-Developers] mailpasswds In-Reply-To: <13723.62736.17291.209644@glyph.cnri.reston.va.us> Message-ID: On Thu, 2 Jul 1998, Ken Manheimer wrote: > You don't say which version you're running, but we ran into the same 1.0b4 > One fix is to change the "os.forks()" in the scripts/deliver script to > use the following 'forker()' routine, which recognizes errno.EAGAIN, and > retries to fork a specified number of times. (You have to have settings > in the module for TRIES and REFRACT - i use 5 and 15, respectively.) This seems the better solution, since it is more generic. Mailpasswds works now with the other solution, but convert_list and other mass-subscriptions dont. I think this should be included in the next release. > Another solution is to have the mailpasswds script take some time to > do an os.wait() every several users - i'm attaching a version of > cron/mailpasswds for 1.0b4 that does this. As I said, this just fixes mailpasswds, not the others. Thanks, Greg -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Tue Jul 7 20:15:04 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 7 Jul 1998 15:15:04 -0400 (EDT) Subject: [Mailman-Developers] Re: [Mailman-Users] Multilingual support in mailman? References: Message-ID: <13730.29624.78637.79684@anthem.cnri.reston.va.us> >>>>> "GM" == Gergely Madarasz writes: GM> I'd like to see something like that too... for a Hungarian GM> translation :) Actually, my architecture should be expanded a bit to make it work for multiple languages. Currently, there's a function called maketext() in the Utils module that takes a relative filename and a dictionary. The file is pulled out of the templates directory and contains %(key)s for interpolation of the dict. What we'd probably want to add are subdirs inside of templates for the various languages. Then each list would have to have a language option which would get passed to Utils.maketext() so that it could select the appropriate file to use (e.g. templates/en/cronpass.txt would the be English text, templates/hu/cronpass.txt would the be Hungarian, etc.). -Barry From Dan.Ohnesorg@feld.cvut.cz Tue Jul 7 22:43:25 1998 From: Dan.Ohnesorg@feld.cvut.cz (Dan Ohnesorg, admin of POWER) Date: Tue, 7 Jul 1998 23:43:25 +0200 Subject: [Mailman-Developers] Re: [Mailman-Users] Multilingual support in mailman? In-Reply-To: <13730.29624.78637.79684@anthem.cnri.reston.va.us> Message-ID: <17789354532@power.feld.cvut.cz> On 7 Jul 98, at 15:15, Barry A. Warsaw wrote: > Actually, my architecture should be expanded a bit to make it work for > multiple languages. Currently, there's a function called maketext() > in the Utils module that takes a relative filename and a dictionary. > The file is pulled out of the templates directory and contains %(key)s > for interpolation of the dict. > > What we'd probably want to add are subdirs inside of templates for the > various languages. Then each list would have to have a language > option which would get passed to Utils.maketext() so that it could > select the appropriate file to use (e.g. templates/en/cronpass.txt > would the be English text, templates/hu/cronpass.txt would the be > Hungarian, etc.). Very interesting, I will made czech translations. Some sugestion, mailman should select, in which language to respon from top domain name in e-mail. FE ...cz = czech, com = english and so on. cheers dan P.S. Why is there no respon to my patch???? Is so bad??? I think it mades interesting thinks....... ________________________________________ DDDDDD DD DD Dan Ohnesorg, supervisor on POWER DD OOOO Dan@feld.cvut.cz DD OODDOO Dep. of Power Engineering DDDDDD OO CTU FEL Prague, Bohemia OO OO work: +420 2 24352785;+420 2 24972109 OOOO home: +420 311 679679;+420 311 679311 ________________________________________ Kdyz jdes do sebe, nezastavuj pred kazdou hospodou. From viega@list.org Tue Jul 7 22:48:32 1998 From: viega@list.org (John Viega) Date: Tue, 7 Jul 1998 14:48:32 -0700 Subject: [Mailman-Developers] Re: [Mailman-Users] Multilingual support in mailman? In-Reply-To: <17789354532@power.feld.cvut.cz>; from Dan Ohnesorg, admin of POWER on Tue, Jul 07, 1998 at 11:43:25PM +0200 References: <13730.29624.78637.79684@anthem.cnri.reston.va.us> <17789354532@power.feld.cvut.cz> Message-ID: <19980707144832.B30797@list.org> On Tue, Jul 07, 1998 at 11:43:25PM +0200, Dan Ohnesorg, admin of POWER wrote: > > P.S. Why is there no respon to my patch???? Is so bad??? I > think it mades interesting thinks....... Personally, I have been working on a grant proposal for the past couple of weeks, and haven't had any time for outside activities. However, I'll look at it soon. John From gorgo@caesar.elte.hu Wed Jul 8 16:53:49 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Wed, 8 Jul 1998 17:53:49 +0200 (METDST) Subject: [Mailman-Developers] default digest mode Message-ID: Hello! It seems that setting default digest mode to plain has no effect at all... I could not find anything related to this in ApprovedAddMember, and i guess, it should be there... is this known ? -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From gorgo@caesar.elte.hu Wed Jul 8 18:09:27 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Wed, 8 Jul 1998 19:09:27 +0200 (METDST) Subject: [Mailman-Developers] default digest mode In-Reply-To: Message-ID: On Wed, 8 Jul 1998, Gergely Madarasz wrote: > It seems that setting default digest mode to plain has no effect at all... > I could not find anything related to this in ApprovedAddMember, and i > guess, it should be there... is this known ? Well... replying to myself is fun ;) I tried myself a bit with python (never used it before :)), and found a solution: I need a line self.SetUserOption(name,mm_cfg.DisableMime,1-self.mime_is_default_digest) right after the self.digest_members.append(name) line in ApprovedAddMember :) Greg -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From gorgo@caesar.elte.hu Thu Jul 9 19:46:46 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Thu, 9 Jul 1998 20:46:46 +0200 (METDST) Subject: [Mailman-Developers] error handling Message-ID: Hello! There is a bug in 1.0b4... if someone tries to subscribe while he is already subscribed, he does not get an explanation message, but an error message from sendmail stating "Unknown mailer error". MMAlreadyAMember should be handled here Greg -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Thu Jul 9 20:06:31 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 9 Jul 1998 15:06:31 -0400 (EDT) Subject: [Mailman-Developers] error handling References: Message-ID: <13733.5303.486168.936963@anthem.cnri.reston.va.us> >>>>> "GM" == Gergely Madarasz writes: GM> There is a bug in 1.0b4... if someone tries to subscribe while GM> he is already subscribed, he does not get an explanation GM> message, but an error message from sendmail stating "Unknown GM> mailer error". MMAlreadyAMember should be handled here I think Ken discovered this bug too, but I'm not sure it's been fixed in our current working copy. It definitely needs to be though. -Barry From klm@python.org Thu Jul 9 20:06:41 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 9 Jul 1998 15:06:41 -0400 (EDT) Subject: [Mailman-Developers] error handling In-Reply-To: Message-ID: On Thu, 9 Jul 1998, Gergely Madarasz wrote: > There is a bug in 1.0b4... if someone tries to subscribe while he is > already subscribed, he does not get an explanation message, but an error > message from sendmail stating "Unknown mailer error". MMAlreadyAMember > should be handled here This is a known bug, and it will be fixed in the next release. (I say this with confidence, though i haven't gotten time to investigate it yet - i actually plan to do so in the next couple of days.) I'll try to package a 1.0b4 fix, in addition to the doing the work on our internal development copy. ken manheimer klm@python.org From janne@avocado.pc.helsinki.fi Sat Jul 11 00:05:53 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 11 Jul 1998 02:05:53 +0300 Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem Message-ID: There exists a problem with MIME digests of b4 and some MTAs. Something in some digests makes the receiving end to think that it has received the whole message, while the sending MTA (mine was sendmail 8.8.5, now 8.9.1) thinks it failed and leaves the message to the spool. The message needs to be removed manually, for otherwise the poor subscriber will get a copy of it every time the mail queue is run, indefinitely. Does anybody know a remedy? I'm leaving for a holiday soon, and wouldn't like to write a script to be able to delete digests through my mobile phone... A maybe-related problem is that some messages are left to the mail spool even if they are expired. Apparently his has only happened with mailman, not with majordomo. (I just deleted a few thousands, the oldest dated May 1998.) Sounds like a sendmail problem, but I don't understand how it's related to mailman. -- Janne From viega@list.org Sat Jul 11 00:06:19 1998 From: viega@list.org (John Viega) Date: Fri, 10 Jul 1998 16:06:19 -0700 Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: ; from Janne Sinkkonen on Sat, Jul 11, 1998 at 02:05:53AM +0300 References: Message-ID: <19980710160619.A32600@list.org> Odd. I can't think of anything I know of that would give that sort of behavior. Can you look at one of these digests and see if there is anything suspect about them?? John On Sat, Jul 11, 1998 at 02:05:53AM +0300, Janne Sinkkonen wrote: > > There exists a problem with MIME digests of b4 and some > MTAs. Something in some digests makes the receiving end to think that > it has received the whole message, while the sending MTA (mine was > sendmail 8.8.5, now 8.9.1) thinks it failed and leaves the message to > the spool. The message needs to be removed manually, for otherwise the > poor subscriber will get a copy of it every time the mail queue is > run, indefinitely. > > Does anybody know a remedy? I'm leaving for a holiday soon, and > wouldn't like to write a script to be able to delete digests through > my mobile phone... > > A maybe-related problem is that some messages are left to the mail > spool even if they are expired. Apparently his has only happened with > mailman, not with majordomo. (I just deleted a few thousands, the > oldest dated May 1998.) Sounds like a sendmail problem, but I don't > understand how it's related to mailman. > > -- > Janne > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers From gorgo@caesar.elte.hu Sat Jul 11 00:25:46 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Sat, 11 Jul 1998 01:25:46 +0200 (METDST) Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: Message-ID: On 11 Jul 1998, Janne Sinkkonen wrote: > > There exists a problem with MIME digests of b4 and some > MTAs. Something in some digests makes the receiving end to think that > it has received the whole message, while the sending MTA (mine was > sendmail 8.8.5, now 8.9.1) thinks it failed and leaves the message to > the spool. The message needs to be removed manually, for otherwise the > poor subscriber will get a copy of it every time the mail queue is > run, indefinitely. This is a bug in sendmail, it segfaults on 8bitmime digests when sending them to hosts which don't support 8bitmime. I already wrote about this to the list a couple of weeks ago. Btw i thought 8.9.1 already has it fixed. Greg -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From klm@python.org Sat Jul 11 00:32:29 1998 From: klm@python.org (Ken Manheimer) Date: Fri, 10 Jul 1998 19:32:29 -0400 (EDT) Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: Message-ID: On Sat, 11 Jul 1998, Gergely Madarasz wrote: > On 11 Jul 1998, Janne Sinkkonen wrote: > > There exists a problem with MIME digests of b4 and some > > MTAs. Something in some digests makes the receiving end to think that > > it has received the whole message, while the sending MTA (mine was > > sendmail 8.8.5, now 8.9.1) thinks it failed and leaves the message to > > the spool. The message needs to be removed manually, for otherwise the > > poor subscriber will get a copy of it every time the mail queue is > > run, indefinitely. > > This is a bug in sendmail, it segfaults on 8bitmime digests when sending > them to hosts which don't support 8bitmime. I already wrote about this to > the list a couple of weeks ago. Btw i thought 8.9.1 already has it fixed. I also suspect that the sendmail problem is causing this particular behavior - check your mqeue for sendmail core dumps to confirm. I'm running sendmail 8.9.0 on python.org as of recently, and had to apply the patch that gergely sent me (thanks again, gergely) to get around the problem. I'm posting it here, for anyone that's interested and for the maillist archive. I think i'll include it and a note about it in the mailman distribution. Of course, this patch doesn't help the recipient sites running sendmail 8.8.x and 8.9.x (for some x'es). Question is, does anyone think we should we be constraining the digester to 7-bit mime messages - presumably stripping the 8th bit from messages that have it - just for the sake of a current bug in the most prominent MTA? I'd be loathe to do that, thinking that the bug should be exposed and get fixed. Ken *** collect.c.orig Wed May 20 02:36:05 1998 --- collect.c Thu May 28 13:29:09 1998 *************** *** 353,360 **** if (*--bp != '\n' || *--bp != '\r') bp++; *bp = '\0'; ! if (bitset(H_EOH, chompheader(buf, FALSE, hdrp, e))) ! mstate = MS_BODY; break; case MS_BODY: --- 353,364 ---- if (*--bp != '\n' || *--bp != '\r') bp++; *bp = '\0'; ! if (bitset(H_EOH, chompheader(buf, FALSE, hdrp, e))) { ! mstate = MS_BODY; ! if (tTd(30, 35)) ! printf("H_EOH, istate=%d, mstate=%d\n", istate, mstate); ! goto nextstate; ! } break; case MS_BODY: From janne@avocado.pc.helsinki.fi Sat Jul 11 00:37:45 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 11 Jul 1998 02:37:45 +0300 Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: Gergely Madarasz's message of "Sat, 11 Jul 1998 01:25:46 +0200 (METDST)" References: Message-ID: Gergely Madarasz writes: > This is a bug in sendmail, it segfaults on 8bitmime digests when sending > them to hosts which don't support 8bitmime. I already wrote about this to > the list a couple of weeks ago. Btw i thought 8.9.1 already has it fixed. Thanks a lot - seems like I should read some archives... I installed 8.9.1 just an hour ago, so haven't really given it a try yet. The problems appeared with 8.8.5. -- Janne From Gergely Madarasz Sat Jul 11 00:46:18 1998 From: Gergely Madarasz (Gergely Madarasz) Date: Sat, 11 Jul 1998 01:46:18 +0200 (METDST) Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: Message-ID: On Fri, 10 Jul 1998, Ken Manheimer wrote: > Of course, this patch doesn't help the recipient sites running sendmail > 8.8.x and 8.9.x (for some x'es). Question is, does anyone think we It causes segfault only when sendmail tries to convert it from 8bit to 7bit. So the problem could be only at recipients whose secondary MX is sendmail, the primary does not know 8bitmime, and the primary can't be reached for a while. > should we be constraining the digester to 7-bit mime messages - > presumably stripping the 8th bit from messages that have it - just for > the sake of a current bug in the most prominent MTA? I'd be loathe to That would not be a solution... just think of all non-english mailing lists. I just remembered something else about the digests... could it be possible to strip the non-essential headers from the plaintext digest ? I got lots of complaints about them since I switched from majordomo. The From: header, and the Subject: could be enough.... Greg -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From klm@python.org Sat Jul 11 00:47:02 1998 From: klm@python.org (Ken Manheimer) Date: Fri, 10 Jul 1998 19:47:02 -0400 (EDT) Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: Message-ID: On Sat, 11 Jul 1998, Gergely Madarasz wrote: > I just remembered something else about the digests... could it be possible > to strip the non-essential headers from the plaintext digest ? I got lots > of complaints about them since I switched from majordomo. The From: > header, and the Subject: could be enough.... This one is one my list - i've heard this complaint from several people. Ken From klm@python.org Sat Jul 11 00:49:51 1998 From: klm@python.org (Ken Manheimer) Date: Fri, 10 Jul 1998 19:49:51 -0400 (EDT) Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: Message-ID: On Sat, 11 Jul 1998, Gergely Madarasz wrote: > On Fri, 10 Jul 1998, Ken Manheimer wrote: > > It causes segfault only when sendmail tries to convert it from 8bit to > 7bit. So the problem could be only at recipients whose secondary MX is > sendmail, the primary does not know 8bitmime, and the primary can't be > reached for a while. Ah! That sort of thing would help explain why i've so rarely heard about problems from recipients. And it would explain why the problem would show at the mailman site - they communicate with many sites, some of which may well have the 7bit restriction. Ken From klm@python.org Sat Jul 11 00:51:25 1998 From: klm@python.org (Ken Manheimer) Date: Fri, 10 Jul 1998 19:51:25 -0400 (EDT) Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: Message-ID: One more thing re the sendmail problem - if it still does exist in 8.9.1, some of us should write sendmail.org and complain. Considering that it's a known and disruptive bug (they had it in the known-bugs list for 8.9.0), it should have been stomped! Ken From viega@list.org Sat Jul 11 00:53:05 1998 From: viega@list.org (John Viega) Date: Fri, 10 Jul 1998 16:53:05 -0700 Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: ; from Ken Manheimer on Fri, Jul 10, 1998 at 07:47:02PM -0400 References: Message-ID: <19980710165305.A651@list.org> Was it not originally this way?? When/why did it change? John On Fri, Jul 10, 1998 at 07:47:02PM -0400, Ken Manheimer wrote: > On Sat, 11 Jul 1998, Gergely Madarasz wrote: > > > I just remembered something else about the digests... could it be possible > > to strip the non-essential headers from the plaintext digest ? I got lots > > of complaints about them since I switched from majordomo. The From: > > header, and the Subject: could be enough.... > > This one is one my list - i've heard this complaint from several people. > > Ken > > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers From janne@avocado.pc.helsinki.fi Sat Jul 11 01:01:42 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 11 Jul 1998 03:01:42 +0300 Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: Ken Manheimer's message of "Fri, 10 Jul 1998 19:51:25 -0400 (EDT)" References: Message-ID: Ken Manheimer writes: > One more thing re the sendmail problem - if it still does exist in > 8.9.1, some of us should write sendmail.org and complain. Considering > that it's a known and disruptive bug (they had it in the known-bugs list > for 8.9.0), it should have been stomped! collect.c seems like having the patch included. You're right in that the problem has been very annoying. Suddenly (no more missing digests, no more mail spool fiddling) mailman feels much better. -- Janne From gorgo@caesar.elte.hu Sat Jul 11 01:04:53 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Sat, 11 Jul 1998 02:04:53 +0200 (METDST) Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: Message-ID: On Fri, 10 Jul 1998, Ken Manheimer wrote: > One more thing re the sendmail problem - if it still does exist in > 8.9.1, some of us should write sendmail.org and complain. Considering > that it's a known and disruptive bug (they had it in the known-bugs list > for 8.9.0), it should have been stomped! The changelog for 8.9.1 says it is fixed. Greg -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From klm@python.org Sat Jul 11 01:00:44 1998 From: klm@python.org (Ken Manheimer) Date: Fri, 10 Jul 1998 20:00:44 -0400 (EDT) Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: <19980710165305.A651@list.org> Message-ID: On Fri, 10 Jul 1998, John Viega wrote: > Was it not originally this way?? When/why did it change? My fault - i added in more to the headers, missing the info myself, and thinking that good MIME mua's could manage the display nicely. Oh well, i think i'll just cut them back a lot - though probably not completely... Ken From viega@list.org Sat Jul 11 01:00:18 1998 From: viega@list.org (John Viega) Date: Fri, 10 Jul 1998 17:00:18 -0700 Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: ; from Ken Manheimer on Fri, Jul 10, 1998 at 08:00:44PM -0400 References: <19980710165305.A651@list.org> Message-ID: <19980710170018.A889@list.org> Wasn't the request for on non-MIME digests? I don't mind so much w/ MIME. Also, if we reorganize a few things to avoid filtering for each message (by caching stuff), it would be acceptable to let the user set verbose headers as an option. On Fri, Jul 10, 1998 at 08:00:44PM -0400, Ken Manheimer wrote: > On Fri, 10 Jul 1998, John Viega wrote: > > > Was it not originally this way?? When/why did it change? > > My fault - i added in more to the headers, missing the info myself, and > thinking that good MIME mua's could manage the display nicely. Oh well, > i think i'll just cut them back a lot - though probably not > completely... > > Ken From klm@python.org Sat Jul 11 01:08:23 1998 From: klm@python.org (Ken Manheimer) Date: Fri, 10 Jul 1998 20:08:23 -0400 (EDT) Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: <19980710170018.A889@list.org> Message-ID: On Fri, 10 Jul 1998, John Viega wrote: > Wasn't the request for on non-MIME digests? I don't mind so much w/ > MIME. Also, if we reorganize a few things to avoid filtering for each > message (by caching stuff), it would be acceptable to let the user set > verbose headers as an option. The reason i was considering reducing the headers in both is because currently they're congruent - the same file contains them both. I don't think i'll have time to refine that very much, because there's higher priority stuff to tackle. We'll see though - eventually, messages pending digest should be stored in some kind of catalogue, enabling more discretion in their handling... Ken From gorgo@caesar.elte.hu Sat Jul 11 01:41:05 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Sat, 11 Jul 1998 02:41:05 +0200 (METDST) Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: Message-ID: On Fri, 10 Jul 1998, Ken Manheimer wrote: > On Fri, 10 Jul 1998, John Viega wrote: > > > Wasn't the request for on non-MIME digests? I don't mind so much w/ > > MIME. Also, if we reorganize a few things to avoid filtering for each > > message (by caching stuff), it would be acceptable to let the user set > > verbose headers as an option. > > The reason i was considering reducing the headers in both is because > currently they're congruent - the same file contains them both. I see... but I think it is nice to have the headers in the mime digest - it keeps the mails full, with content information, etc. The best solution would be to filter out the extra headers at digest-creation time and only when creating the plaintext digest. Greg -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From klm@python.org Sat Jul 11 01:48:51 1998 From: klm@python.org (Ken Manheimer) Date: Fri, 10 Jul 1998 20:48:51 -0400 (EDT) Subject: [Mailman-Developers] A (the?) MIME digest / MTA problem In-Reply-To: Message-ID: On Sat, 11 Jul 1998, Gergely Madarasz wrote: > I see... but I think it is nice to have the headers in the mime digest - > it keeps the mails full, with content information, etc. The best solution > would be to filter out the extra headers at digest-creation time and only > when creating the plaintext digest. That's very likely what i'll do - if you look in mm_digest.py, there's 'present'ation method which can do all the reduction work, shouldn't be hard. Ken From gorgo@caesar.elte.hu Sun Jul 12 15:35:35 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Sun, 12 Jul 1998 16:35:35 +0200 (METDST) Subject: [Mailman-Developers] big problems Message-ID: Hello! Two of my lists arent working. The error log says: Jul 12 16:22:30 1998 post: Traceback (innermost last): post: File "/var/lib/mailman/scripts/mailowner", line 40, in ? post: current_list = maillist.MailList(sys.argv[1]) post: File "/var/lib/mailman/Mailman/maillist.py", line 64, in __init__ post: self.Load() post: File "/var/lib/mailman/Mailman/maillist.py", line 554, in Load post: raise mm_cfg.MMBadListError, 'Failed to unmarshal config info' post: AttributeError : MMBadListError What could have caused this and how do I fix it ? Greg -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From janne@avocado.pc.helsinki.fi Mon Jul 13 10:35:35 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: Mon, 13 Jul 1998 12:35:35 +0300 Subject: [Mailman-Developers] A logging bug (and a patch) Message-ID: <199807130935.MAA21245@avocado.pc.helsinki.fi> I got these when a listadmin tried to approve/discard messages: Jul 13 12:13:23 1998 admindb: Traceback (innermost last): admindb: File "/home/mailman/scripts/admindb", line 232, in ? admindb: HandleRequests(doc) admindb: File "/home/mailman/scripts/admindb", line 125, in HandleRequests admindb: list.HandleRequest(request, v, form[comment_key].value) admindb: File "/home/mailman/Mailman/mm_admin.py", line 137, in HandleRequest admindb: self.HandlePostRequest(request_data[2:], value, comment) admindb: File "/home/mailman/Mailman/mm_admin.py", line 174, in HandlePostRequ est admindb: self.LogMsg("vette", note) admindb: File "/home/mailman/Mailman/maillist.py", line 570, in LogMsg admindb: logf.write("%s\n" % (msg % args)) admindb: TypeError : not enough arguments for format string The reasons was that one of the messages had '18% grey card' on the subject line. :) Here's patch: --- mm_admin.py~ Thu Jun 4 23:12:28 1998 +++ mm_admin.py Mon Jul 13 12:31:06 1998 @@ -171,6 +171,7 @@ note = note + "\n\tHeld: %s" % data[1] if comment: note = note + "\n\tDiscarded: %s" % comment + note = string.replace(note,'%','%%') self.LogMsg("vette", note) def HandleAddMemberRequest(self, data, value, comment): ... although I'm not sure whether this is a generic enough way to handle the problem. -- Janne From gorgo@caesar.elte.hu Mon Jul 13 23:06:21 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Tue, 14 Jul 1998 00:06:21 +0200 (METDST) Subject: [Mailman-Developers] port 25 problem Message-ID: Hello! I've found another problem... if the cronjob that creates the digest runs at a time when sendmail is down (dunno why but it may happen), then it is lost. It would be nicer if mailman used sendmail directly, and not thru port 25. -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From viega@list.org Mon Jul 13 23:24:47 1998 From: viega@list.org (John Viega) Date: Mon, 13 Jul 1998 15:24:47 -0700 Subject: [Mailman-Developers] port 25 problem In-Reply-To: ; from Gergely Madarasz on Tue, Jul 14, 1998 at 12:06:21AM +0200 References: Message-ID: <19980713152447.A2069@list.org> This problem is known. Unfortunately, calling sendmail is highly unportable. The next release will queue up messages until sendmail becomes available. If I have time, you'll be able to call sendmail as instead, as an option. John On Tue, Jul 14, 1998 at 12:06:21AM +0200, Gergely Madarasz wrote: > Hello! > > I've found another problem... if the cronjob that creates the digest runs > at a time when sendmail is down (dunno why but it may happen), then it is > lost. It would be nicer if mailman used sendmail directly, and not thru > port 25. > > -- > Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org > It's practically impossible to look at a penguin and feel angry. > Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. > HuLUG: http://www.cab.u-szeged.hu/local/linux/ > > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers From klm@python.org Tue Jul 14 05:21:56 1998 From: klm@python.org (Ken Manheimer) Date: Tue, 14 Jul 1998 00:21:56 -0400 (EDT) Subject: [Mailman-Developers] Some patch for mailman In-Reply-To: Message-ID: On Wed, 1 Jul 1998, Dan Ohnesorg, admin on power wrote: > Hi everybody, Hi, dan. Sorry it's taken so long to respond - i for one haven't had much time to do a lot of pending mailman stuff, including looking at your patches, until now. > What it solves, first part of patch to remove irriting headers from messages. I dont > like to send messages like RCPT and so. Second uses DSN to send mails. This > disables (when enabled) messages like warning, message is not delivered for 4 > hours and so. Then comes some removing of winmail.dat binary attachments. I am > working on removing all unwanted parts (html, rtf) and translating national > characters into ascii, but is not complete yet. Then comes administrativ via filter, but > it not works, it worked on mailman 1.0, but I cannot bring it running on b4, You will > see, it is probably only a little bug, at least the filter shields list from administrative > messages. The main thing that interests me is the DSN capability. It may be that we'll integrate it for the next release. I'm reluctant to do any administrivia filtering that catches anything but the most mechanical administrivia - i do not want to try to catch messages like "How do i subscribe to the list?", only those that were strictly formatted and intended for the -request address. I also wouldn't recommend doing translation of stuff to ascii, or other surgery on messages. Minimum intrusion is the rule - granted, stuff like winmail.dat attachments are a nuisance, but it seems like the problem is with the origin, and not something a relatively transparent maillist should be trying to fix. ken manheimer klm@python.org From klm@python.org Tue Jul 14 05:29:18 1998 From: klm@python.org (Ken Manheimer) Date: Tue, 14 Jul 1998 00:29:18 -0400 (EDT) Subject: [Mailman-Developers] big problems In-Reply-To: Message-ID: On Sun, 12 Jul 1998, Gergely Madarasz wrote: > Two of my lists arent working. The error log says: > > Jul 12 16:22:30 1998 post: Traceback (innermost last): > post: File "/var/lib/mailman/scripts/mailowner", line 40, in ? > post: current_list = maillist.MailList(sys.argv[1]) > post: File "/var/lib/mailman/Mailman/maillist.py", line 64, in __init__ > post: self.Load() > post: File "/var/lib/mailman/Mailman/maillist.py", line 554, in Load > post: raise mm_cfg.MMBadListError, 'Failed to unmarshal config info' > post: AttributeError : MMBadListError > > What could have caused this and how do I fix it ? Sounds like the config.db for the lists somehow got corrupted. I haven't seen this happen to any of the python.org or other lists i run (mostly 1.0b4, some with the current development code). Did you find any prior errors in the error log? Any abnormal incidents on the host leading up to it?? If you'd like, you could send me a (mime-attached or uuencoded tar archive) copy of the config.db files for each of the lists, and i can see if there's anything i can glean, and salvalge, from them... Ken Manheimer klm@python.org 703 620-8990 x268 (orporation for National Research |nitiatives # If you appreciate Python, consider joining the PSA! # # . # From Dan@feld.cvut.cz Tue Jul 14 09:25:46 1998 From: Dan@feld.cvut.cz (Dan Ohnesorg, admin on power) Date: Tue, 14 Jul 1998 10:25:46 +0200 Subject: [Mailman-Developers] Some patch for mailman In-Reply-To: References: Message-ID: <212401917E1@power.feld.cvut.cz> On 14 Jul 98, at 0:21, Ken Manheimer wrote: > On Wed, 1 Jul 1998, Dan Ohnesorg, admin on power wrote: Hi Ken, > > > Hi everybody, > > Hi, dan. Sorry it's taken so long to respond - i for one haven't had > much time to do a lot of pending mailman stuff, including looking at > your patches, until now. No problemo. > I'm reluctant to do any administrivia filtering that catches anything > but the most mechanical administrivia - i do not want to try to catch > messages like "How do i subscribe to the list?", only those that were > strictly formatted and intended for the -request address. Yes it is that, what my patch mades, it looks on first word on first 10 lines in message and when it founds command for listserv, it redirects the message. I think it will work fine, but I have following problem.. Jul 03 13:29:51 1998 post: Traceback (innermost last): post: File "/home/mailman/scripts/post", line 102, in ? post: current_list.ParseMailCommands() post: File "/home/mailman/Mailman/mm_mailcmd.py", line 80, in ParseMailCommands post: sender = string.lower(mail.GetSender()) post: File "/home/mailman/Mailman/mm_message.py", line 115, in GetSender post: return string.lower(mail_address) post: TypeError : read-only buffer, None I think there is nothing bad, return modifies nothing. > > I also wouldn't recommend doing translation of stuff to ascii, or other > surgery on messages. Minimum intrusion is the rule - granted, stuff > like winmail.dat attachments are a nuisance, but it seems like the > problem is with the origin, and not something a relatively transparent > maillist should be trying to fix. Yes it is problem in origin. Problem in origin is also that smail many years corupts messages consisting CRLF.CRLF in body and mailman includes fix for that. I have list with 500 subscribers and 50 mesages per day, when I shall distribute unwanted parts of this messages, I am worried. It takes many MB, winmail.dat is many times bigger than mail itself. It makes archive big and slowes searching or at least indexing. And it slowes delivery. Many peoples cannot read correctly mesages with ms-tnef and html part and I will give them posibility to become readable messages. My vision is, that there should be posibility to send command like set ascii to become pure ascii messages. I hope You will also include that part, which removes some headers, like confirm-delivery-to:, I will send more patterns soon. Yesterday I have shown RFC for delivery confirmation messages and there are some headers, which are not intended for public redistribute over maillists. cheers dan ________________________________________ DDDDDD DD DD Dan Ohnesorg, supervisor on POWER DD OOOO Dan@feld.cvut.cz DD OODDOO Dep. of Power Engineering DDDDDD OO CVUT FEL Prague, Bohemia OO OO work: +420 2 24352785;+420 2 24972109 OOOO home: +420 311 679679;+420 311 679311 ________________________________________ Kdo se zahledi, neprokoukne. From gorgo@caesar.elte.hu Tue Jul 14 10:33:58 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Tue, 14 Jul 1998 11:33:58 +0200 (METDST) Subject: [Mailman-Developers] big problems In-Reply-To: Message-ID: On Tue, 14 Jul 1998, Ken Manheimer wrote: > > Jul 12 16:22:30 1998 post: Traceback (innermost last): > > post: File "/var/lib/mailman/scripts/mailowner", line 40, in ? > > post: current_list = maillist.MailList(sys.argv[1]) > > post: File "/var/lib/mailman/Mailman/maillist.py", line 64, in __init__ > > post: self.Load() > > post: File "/var/lib/mailman/Mailman/maillist.py", line 554, in Load > > post: raise mm_cfg.MMBadListError, 'Failed to unmarshal config info' > > post: AttributeError : MMBadListError > > > > What could have caused this and how do I fix it ? > > Sounds like the config.db for the lists somehow got corrupted. I > haven't seen this happen to any of the python.org or other lists i run > (mostly 1.0b4, some with the current development code). Did you find > any prior errors in the error log? Any abnormal incidents on the host > leading up to it?? It seems the other admin of the server has done something that crashed the server, so the file corrupted... fortunatelly there was config.db.last Greg -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From janne@avocado.pc.helsinki.fi Tue Jul 14 11:46:18 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 14 Jul 1998 13:46:18 +0300 Subject: [Mailman-Developers] Some patch for mailman In-Reply-To: "Dan Ohnesorg, admin on power"'s message of "Tue, 14 Jul 1998 10:25:46 +0200" References: <212401917E1@power.feld.cvut.cz> Message-ID: "Dan Ohnesorg, admin on power" writes: > I have list with 500 subscribers and 50 mesages per day, when I shall distribute > unwanted parts of this messages, I am worried. It takes many MB, winmail.dat is > many times bigger than mail itself. You can filter on the basis of headers, and reject messages which contain HTML or WINMAIL stuff. We do that and it works well. If you start doing automatically things like removing HTML, there's no end to it. It's better to educate subscribers to behave properly. -- Janne From viega@list.org Tue Jul 14 14:56:32 1998 From: viega@list.org (John Viega) Date: Tue, 14 Jul 1998 06:56:32 -0700 Subject: [Mailman-Developers] big problems In-Reply-To: ; from Gergely Madarasz on Tue, Jul 14, 1998 at 11:33:58AM +0200 References: Message-ID: <19980714065632.B8966@list.org> On Tue, Jul 14, 1998 at 11:33:58AM +0200, Gergely Madarasz wrote: > On Tue, 14 Jul 1998, Ken Manheimer wrote: > > It seems the other admin of the server has done something that crashed the > server, so the file corrupted... fortunatelly there was config.db.last Ah, I'm glad this feature works :) Perhaps if the file can't be loaded, it can try the last file. John From gorgo@caesar.elte.hu Tue Jul 14 15:15:23 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Tue, 14 Jul 1998 16:15:23 +0200 (METDST) Subject: [Mailman-Developers] big problems In-Reply-To: <19980714065632.B8966@list.org> Message-ID: On Tue, 14 Jul 1998, John Viega wrote: > On Tue, Jul 14, 1998 at 11:33:58AM +0200, Gergely Madarasz wrote: > > On Tue, 14 Jul 1998, Ken Manheimer wrote: > > > > It seems the other admin of the server has done something that crashed the > > server, so the file corrupted... fortunatelly there was config.db.last > > Ah, I'm glad this feature works :) Perhaps if the file can't be > loaded, it can try the last file. That would be nice. And warn the admin, of course. Btw it seems I have lost several digests because sendmail did not accept connections on port 25 at that time... it could be a config option not to connect to port 25 but use sendmail -bs so not much should be changed (sendmail -bs talks smtp), just the invocation. -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From viega@list.org Tue Jul 14 15:10:04 1998 From: viega@list.org (John Viega) Date: Tue, 14 Jul 1998 07:10:04 -0700 Subject: [Mailman-Developers] big problems In-Reply-To: ; from Gergely Madarasz on Tue, Jul 14, 1998 at 04:15:23PM +0200 References: <19980714065632.B8966@list.org> Message-ID: <19980714071004.D8966@list.org> On Tue, Jul 14, 1998 at 04:15:23PM +0200, Gergely Madarasz wrote: > > Btw it seems I have lost several digests because sendmail did not accept > connections on port 25 at that time... it could be a config option not to > connect to port 25 but use sendmail -bs so not much should be changed > (sendmail -bs talks smtp), just the invocation. Yeah, this problem is becoming a FAQ. There will be a solution to the problem in the next release, and if I have time, I'll allow an external command to work instead. John From gorgo@caesar.elte.hu Mon Jul 20 22:33:48 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Mon, 20 Jul 1998 23:33:48 +0200 (METDST) Subject: [Mailman-Developers] loosing mail Message-ID: Hello! I'm still loosing digests because mailman wants to use port 25... :( This is a Bad Thing (TM). Any dates about the new release which would fix this? Or is there a patch around for 1.0b4 ? I don't want to switch back to majordomo now :((( -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From klm@python.org Mon Jul 20 23:19:12 1998 From: klm@python.org (Ken Manheimer) Date: Mon, 20 Jul 1998 18:19:12 -0400 (EDT) Subject: [Mailman-Developers] loosing mail In-Reply-To: Message-ID: On Mon, 20 Jul 1998, Gergely Madarasz wrote: > I'm still loosing digests because mailman wants to use port 25... :( > This is a Bad Thing (TM). Any dates about the new release which would fix > this? Or is there a patch around for 1.0b4 ? I don't want to switch back > to majordomo now :((( I'd wait to see what john says - he's working on the queuing stuff - but failing a near fix, you could look at switching back to 1.0b3. The tricky thing is, i'm not sure the 1.0b4 list data structures (config.db) are compatable w/1.0b3, so you might need a conversion function to revert it - changing things like paths, etc. Whatever you do, if you do fool around with reverting, make backup copies of your stuff before tinkering... Ken klm@python.org From viega@list.org Mon Jul 20 23:39:18 1998 From: viega@list.org (John Viega) Date: Mon, 20 Jul 1998 15:39:18 -0700 Subject: [Mailman-Developers] loosing mail In-Reply-To: ; from Ken Manheimer on Mon, Jul 20, 1998 at 06:19:12PM -0400 References: Message-ID: <19980720153918.D13724@list.org> I'm going to try to ready something for tomorrow night. After that, we might try to release weekly snapshots, assuming progress gets made in that week. John On Mon, Jul 20, 1998 at 06:19:12PM -0400, Ken Manheimer wrote: > On Mon, 20 Jul 1998, Gergely Madarasz wrote: > > > I'm still loosing digests because mailman wants to use port 25... :( > > This is a Bad Thing (TM). Any dates about the new release which would fix > > this? Or is there a patch around for 1.0b4 ? I don't want to switch back > > to majordomo now :((( > > I'd wait to see what john says - he's working on the queuing stuff - but > failing a near fix, you could look at switching back to 1.0b3. The > tricky thing is, i'm not sure the 1.0b4 list data structures (config.db) > are compatable w/1.0b3, so you might need a conversion function to > revert it - changing things like paths, etc. Whatever you do, if you do > fool around with reverting, make backup copies of your stuff before > tinkering... > > Ken > klm@python.org > > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Mon Jul 20 23:53:41 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 20 Jul 1998 18:53:41 -0400 (EDT) Subject: [Mailman-Developers] loosing mail References: <19980720153918.D13724@list.org> Message-ID: <13747.51829.799529.285905@anthem.cnri.reston.va.us> >>>>> "JV" == John Viega writes: JV> I'm going to try to ready something for tomorrow night. After JV> that, we might try to release weekly snapshots, assuming JV> progress gets made in that week. I agree. I haven't had time to catch up after vaca, but our montra should be: release early and often! :-) From gorgo@caesar.elte.hu Thu Jul 23 18:05:38 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Thu, 23 Jul 1998 19:05:38 +0200 (METDST) Subject: [Mailman-Developers] URGENT!!!! security problems Message-ID: Hello! There are BIG security problems with mailman. For example a list administrator can subscribe an "email address" like this with mass subscribe: `touch /tmp/gotcha` Then when someone sends mail to the list, the command is executed... this means any list administrator can get access to user running mailman on the list server. I could not achieve the same when trying to subscribe as a normal user, but i cannot say that it is safe. This needs a very urgent fix. Greg Ps. thanks to Endre Hirling for pointing this problem out to me -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From John@list.org Thu Jul 23 18:27:08 1998 From: John@list.org (John Viega) Date: Thu, 23 Jul 1998 10:27:08 -0700 Subject: [Mailman-Developers] URGENT!!!! security problems In-Reply-To: ; from Gergely Madarasz on Thu, Jul 23, 1998 at 07:05:38PM +0200 References: Message-ID: <19980723102708.A13639@viega.org> Actually, that's a known issue. Security stuff is on our todo list, but not much thought has gone into it yet. I hadn't actually put too high a priority on it at this point, since you only need to trust list administrators. It was certainly expected to be done before beta. However, if you want it in sooner, we can move it up. Or, for an even quicker solution, you or someone else could submit patches to either b4, or b5, which will come out perhaps today or tomorrow, but if not, on Monday for sure. It depends on how much time I have to do testing... John On Thu, Jul 23, 1998 at 07:05:38PM +0200, Gergely Madarasz wrote: > Hello! > > There are BIG security problems with mailman. For example a list > administrator can subscribe an "email address" like this with mass > subscribe: > > `touch /tmp/gotcha` > > Then when someone sends mail to the list, the command is executed... this > means any list administrator can get access to user running mailman > on the list server. I could not achieve the same when trying to > subscribe as a normal user, but i cannot say that it is safe. This needs a > very urgent fix. > > Greg > > Ps. thanks to Endre Hirling for pointing this problem > out to me > > -- > Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org > It's practically impossible to look at a penguin and feel angry. > Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. > HuLUG: http://www.cab.u-szeged.hu/local/linux/ > > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers From scott@chronis.icgroup.com Fri Jul 24 04:12:28 1998 From: scott@chronis.icgroup.com (Scott) Date: Thu, 23 Jul 1998 23:12:28 -0400 Subject: [Mailman-Developers] an opinion about using port 25 Message-ID: <19980723231228.64640@chronis.icgroup.com> Something's been bothering me about the use of connecting to port 25 to deliver mail. The goal of this endeavor, if i remember correctly, was to make mailman more portable in it's interface to MTA's. However, I think that it may well make that problem even worse, and that it lies outside what mailman should be doing. Here's the argument: mailman is a mailing list manager, not an MTA. If mailman developers decide to make delivery occur by SMTP, it has to do a LOT of the work that an MTA should be doing: queuing messages, retrying every so often, bouncing messages with appropriate messages under appropriate circumstances (like deferral messages every 4 hours, etc). All this should be the work of the MTA. I also think that it will eventually exacerbate the problems of portability. As a part of test group for a new MTA, and an administrator of a qmail and a sendmail system, I know many work-years of labor goes into making an MTA be able to successfully deliver mail to all the other MTA's out there. This happens because different MTAs act very differently. There are still problems occuring between code as mature as qmail and other MTA's like certain microsoft based products (postoffice, LSOFT for nt, etc). Do we really want to take on that burden? There are other ways we could pursue this. There are basically 2 interfaces to an MTA mailman has to consider: updating aliases and delivering messages. For each of these interfaces, we could create a class hierarchy into which mailman's communication with new MTA's could be easily dropped. Such a structure, coupled with good documentation about how to add support for a new MTA seems to me like it will go further faster than putting a lot of work into SMTP transactions. Such an approach could even include smtp transactions, as a bonus for the daring or those who want mail delivered via a separate machine than the one on which the list manager resides. As far as portability goes, and as far allowing mailman developers to focus on what a list manager should do, i really think that we would do better not depending on a universally reliable way of doing smtp transactions. scott From klm@python.org Fri Jul 24 23:38:12 1998 From: klm@python.org (Ken Manheimer) Date: Fri, 24 Jul 1998 18:38:12 -0400 (EDT) Subject: [Mailman-Developers] an opinion about using port 25 In-Reply-To: <19980723231228.64640@chronis.icgroup.com> Message-ID: On Thu, 23 Jul 1998, Scott wrote: > Something's been bothering me about the use of connecting to port 25 to > deliver mail. > > The goal of this endeavor, if i remember correctly, was to make > mailman more portable in it's interface to MTA's. However, I think > that it may well make that problem even worse, and that it lies > outside what mailman should be doing. > > Here's the argument: > > mailman is a mailing list manager, not an MTA. If mailman developers > decide to make delivery occur by SMTP, it has to do a LOT of the work > that an MTA should be doing: queuing messages, retrying every so > often, bouncing messages with appropriate messages under appropriate > circumstances (like deferral messages every 4 hours, etc). All this > should be the work of the MTA. > > I also think that it will eventually exacerbate the problems of > portability. As a part of test group for a new MTA, and an > administrator of a qmail and a sendmail system, I know many > work-years of labor goes into making an MTA be able to successfully > deliver mail to all the other MTA's out there. This happens because > different MTAs act very differently. There are still problems > occuring between code as mature as qmail and other MTA's like certain > microsoft based products (postoffice, LSOFT for nt, etc). > > Do we really want to take on that burden? Most definitely not! While i adamantly agree that Mailman should not be taking over the duties of an MTA, i do not believe that the recent change amounts to that. The change is in the way that Mailman passes messages to the *local* MTA - it uses SMTP instead of execing the MTA program. This falls far, far short of the general problem of delivery to a general host out on the net. The local MTA still handles all the challenges of getting the messages to the remote site! There are a few significant benefits to this change. Directly contrary to Scott's next point, this drastically reduces portability burdens, because Mailman doesn't need to know *anything* about the specific MTA the local host is running, except that it obeys SMTP. Another big benefit actually addresses the concerns Gergely Madarasz (urgently) raised yesterday. By using the specialized protocol, we don't need to expose any of the addresses or other incidentals to processing by the system shell. (The addresses were still being exposed in other popen's, further upstream, but i changed that in the development code, which should be released soon. I did a quick check for other os.popen's and and os.systems, and most looked safe, but we still have yet to do a thorough examination for security sake.) There are related literal-mangling problems associated with exposing strings to the shell, which we also circumvent by direct protocol transmission. This change may also enable us to exploit advanced SMTP capabilities, like the DSN mod that dan ohnesorg has proposed (inhibiting those annoying "Warning: not yet delivered after 4 hours, will keep trying (and telling you about it)" messages). There are two drawbacks i can see to this approach, both easily surmountable. One is that we *do* have to make provisions for systems where the MTA is not always available. This amounts to a drastically scaled-down version of the general delivery-to-an-unavailable host, and has none of the nuances of the more general problem. It is addressed in the working code. The other is in handling delivery failures for destinations that happen to be local to the local MTA. These are the only deliveries that will be immediately recognized and refused. In this case we don't get the benefit of bounce messages to recognize bad recipients, and we have to make sure that the deliveries to valid recipients on the local host are not disrupted. The latter part has been taken care of in the working copy, and the former part has to be, but no great disruption is caused by it, in any case. > There are other ways we could pursue this. There are basically 2 > interfaces to an MTA mailman has to consider: updating aliases and > delivering messages. For each of these interfaces, we could create a > class hierarchy into which mailman's communication with new MTA's > could be easily dropped. Such a structure, coupled with good > documentation about how to add support for a new MTA seems to me like > it will go further faster than putting a lot of work into SMTP > transactions. Such an approach could even include smtp transactions, > as a bonus for the daring or those who want mail delivered via a > separate machine than the one on which the list manager resides. I don't agree. I'd rather solve, once and for all, connecting via SMTP to the local MTA, and having to handle queueing messages at times the MTA is unavailable, than developing a general plug in framework for a command-based interface with every MTA that's ever going to come down the road. That doesn't sound like an tidy problem to me. Ken From klm@python.org Fri Jul 24 23:41:17 1998 From: klm@python.org (Ken Manheimer) Date: Fri, 24 Jul 1998 18:41:17 -0400 (EDT) Subject: [Mailman-Developers] URGENT!!!! security problems In-Reply-To: <19980723102708.A13639@viega.org> Message-ID: On Thu, 23 Jul 1998, John Viega wrote: > Actually, that's a known issue. Security stuff is on our todo list, > but not much thought has gone into it yet. I hadn't actually put too > high a priority on it at this point, since you only need to trust list > administrators. It was certainly expected to be done before beta. > However, if you want it in sooner, we can move it up. Or, for an even > quicker solution, you or someone else could submit patches to either > b4, or b5, which will come out perhaps today or tomorrow, but if not, > on Monday for sure. It depends on how much time I have to do > testing... As i mentioned in my prior message, this has been addressed in the working copy, so we're no longer interested in other patches for it. (We will be interested in exercise of the fixes, of course, once they're released...) Ken klm@python.org From gorgo@caesar.elte.hu Fri Jul 24 23:59:24 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Sat, 25 Jul 1998 00:59:24 +0200 (METDST) Subject: [Mailman-Developers] an opinion about using port 25 In-Reply-To: Message-ID: On Fri, 24 Jul 1998, Ken Manheimer wrote: > The change is in the way that Mailman passes messages to the *local* MTA > - it uses SMTP instead of execing the MTA program. This falls far, far > short of the general problem of delivery to a general host out on the > net. The local MTA still handles all the challenges of getting the > messages to the remote site! > > There are a few significant benefits to this change. Directly contrary > to Scott's next point, this drastically reduces portability burdens, > because Mailman doesn't need to know *anything* about the specific MTA > the local host is running, except that it obeys SMTP. As I said in one of my previous postings... sendmail can be called from the command line to talk SMTP just like as connected to port 25 (sendmail -bs). I expect most other MTA's have the same features, with perhaps a bit different command line. So the only difference between using a local MTA and connecting to port 25 would be to open a two way pipe to 'sendmail -bs' or whatever (all sendmail-compatible mta-s, like exim or smail should have sendmail -bs) instead of connecting to port 25. All the rest is the same. So the only change needed here would be in the connect function of smtplib -> not a mailman issue but a python issue :) This would be much-much nicer than mailman trying to queue mails. Greg -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From gorgo@caesar.elte.hu Sat Jul 25 00:02:35 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Sat, 25 Jul 1998 01:02:35 +0200 (METDST) Subject: [Mailman-Developers] an opinion about using port 25 In-Reply-To: Message-ID: On Sat, 25 Jul 1998, Gergely Madarasz wrote: > 'sendmail -bs' or whatever (all sendmail-compatible mta-s, like exim or > smail should have sendmail -bs) instead of connecting to port 25. All the Of course, all these optional, depending on some parameters passed to smtplib or some defaults... with fallback to port 25. -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From scott@chronis.icgroup.com Sat Jul 25 18:09:57 1998 From: scott@chronis.icgroup.com (Scott) Date: Sat, 25 Jul 1998 13:09:57 -0400 Subject: [Mailman-Developers] [gorgo@caesar.elte.hu: Re: [Mailman-Developers] URGENT!!!! security problems] Message-ID: <19980725130957.37546@chronis.icgroup.com> -----Forwarded message from Gergely Madarasz ----- Found the problem. ValidEmail is called only from AddMember, not from ApprovedAddMember. So the listowner can subscribe invalid addresses. -------------------- mmm... something must not have made it's way into the patches for 1.0b4. my working copy has ValidEmail called in ApprovedAddMember but 1.0b4 does not. don't know if that was my fault or not, but i think adding a ValidEmail call to ApprovedAddMember is the right way to go: it should be harmless when ApprovedAddMember is called from the mail_cmd interface since it's already been called in AddMember, and it does fix the security problem. scott From John@list.org Mon Jul 27 02:29:45 1998 From: John@list.org (John Viega) Date: Sun, 26 Jul 1998 18:29:45 -0700 Subject: [Mailman-Developers] an opinion about using port 25 In-Reply-To: ; from Gergely Madarasz on Sat, Jul 25, 1998 at 12:59:24AM +0200 References: Message-ID: <19980726182945.A27993@viega.org> On Sat, Jul 25, 1998 at 12:59:24AM +0200, Gergely Madarasz wrote: > > As I said in one of my previous postings... sendmail can be called from > the command line to talk SMTP just like as connected to port 25 > (sendmail -bs). I expect most other MTA's have the same features, with > perhaps a bit different command line. That's definitely not the case for a few MTA's, and it's definitely not something I would want to count on even if it were. From gorgo@caesar.elte.hu Mon Jul 27 03:09:47 1998 From: gorgo@caesar.elte.hu (Gergely Madarasz) Date: Mon, 27 Jul 1998 04:09:47 +0200 (METDST) Subject: [Mailman-Developers] an opinion about using port 25 In-Reply-To: <19980726182945.A27993@viega.org> Message-ID: On Sun, 26 Jul 1998, John Viega wrote: > > On Sat, Jul 25, 1998 at 12:59:24AM +0200, Gergely Madarasz wrote: > > > > As I said in one of my previous postings... sendmail can be called from > > the command line to talk SMTP just like as connected to port 25 > > (sendmail -bs). I expect most other MTA's have the same features, with > > perhaps a bit different command line. > > That's definitely not the case for a few MTA's, and it's definitely > not something I would want to count on even if it were. Don't count on it, just make it an option :) I'd use it here and now. Unfortunatelly I'm just a beginner in python... -- Madarasz Gergely gorgo@caesar.elte.hu gorgo@linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://www.cab.u-szeged.hu/local/linux/ From Dan@feld.cvut.cz Sat Jul 25 22:23:03 1998 From: Dan@feld.cvut.cz (Dan Ohnesorg, admin of POWER) Date: Sat, 25 Jul 1998 23:23:03 +0200 Subject: [Mailman-Developers] an opinion about using port 25 In-Reply-To: References: Message-ID: <3272A6A6B51@power.feld.cvut.cz> On 25 Jul 98, at 0:59, Gergely Madarasz wrote: > As I said in one of my previous postings... sendmail can be called from > the command line to talk SMTP just like as connected to port 25 > (sendmail -bs). I expect most other MTA's have the same features, with > perhaps a bit different command line. So the only difference between using > a local MTA and connecting to port 25 would be to open a two way pipe to > 'sendmail -bs' or whatever (all sendmail-compatible mta-s, like exim or > smail should have sendmail -bs) instead of connecting to port 25. All the > rest is the same. So the only change needed here would be in the connect > function of smtplib -> not a mailman issue but a python issue :) > This would be much-much nicer than mailman trying to queue mails. I have made patch, which uses delivery status notification. This will be probably included in some of next revision. I have not found some posibility, how detect ob MTA knows this feature, other than parsing respond to EHLO request. Delivery status notification is very nice feature, I am using only notify=failure and the list is shielded before warnigs like, mail was not delivered within 4 hours and so. cheers dan ________________________________________ DDDDDD DD DD Dan Ohnesorg, supervisor on POWER DD OOOO Dan@feld.cvut.cz DD OODDOO Dep. of Power Engineering DDDDDD OO CTU FEL Prague, Bohemia OO OO work: +420 2 24352785;+420 2 24972109 OOOO home: +420 311 679679;+420 311 679311 ________________________________________ Pesimista vidi v ementalskem syru jen ty diry. From dragondm@delta.integral.org Mon Jul 27 11:20:18 1998 From: dragondm@delta.integral.org (The Dragon De Monsyne) Date: Mon, 27 Jul 1998 05:20:18 -0500 (CDT) Subject: [Mailman-Developers] an opinion about using port 25 In-Reply-To: <3272A6A6B51@power.feld.cvut.cz> Message-ID: On Sat, 25 Jul 1998, Dan Ohnesorg, admin of POWER wrote: > On 25 Jul 98, at 0:59, Gergely Madarasz wrote: > > > As I said in one of my previous postings... sendmail can be called from > > the command line to talk SMTP just like as connected to port 25 > > (sendmail -bs). I expect most other MTA's have the same features, with > > perhaps a bit different command line. So the only difference between using > > a local MTA and connecting to port 25 would be to open a two way pipe to > > 'sendmail -bs' or whatever (all sendmail-compatible mta-s, like exim or > > smail should have sendmail -bs) instead of connecting to port 25. All the > > rest is the same. So the only change needed here would be in the connect > > function of smtplib -> not a mailman issue but a python issue :) > > This would be much-much nicer than mailman trying to queue mails. > > I have made patch, which uses delivery status notification. This > will be probably included in some of next revision. I have not > found some posibility, how detect ob MTA knows this feature, > other than parsing respond to EHLO request. Delivery status > notification is very nice feature, I am using only notify=failure and > the list is shielded before warnigs like, mail was not delivered > within 4 hours and so. hmmm... Well, parsing the ehlo responce _is_ the proper way to detect support for any esmtp feature, like DSN. I also want to point out that the latest version of the smtplib included in the python distribution (which is NOT the same as mailman's smtplib) has full ESMTP support. This latest version (http://www.integral.org/~dragondm/python/smtplib.py) will be the smtplib included in the python 1.5.2 distribution. Also, unless someone else does it first, as soon as I can get the latest 1.0b5 code [1], I will be submitting patches for mailman to substitute this smtplib for the one currently included with mailman. The reason for that is that way, any improvements/bugfixes to the module could eventually be folded into the next python distribution. Now, as for 'sendmail -bs' well, yes you could do that. with the python smtplib, it would be a matter of subclassing smtplib.SMTP and overriding the methods that open, read from, and write to the socket, however I would reccomend against it. If the local smtp listener is refusing messages, 9 times out of ten there is a good reason for it (perhaps the server's overloaded). The best choice is for mailman to queue the message, and fer a cron job or such to try again later. Port 25 smtp is the 'universal' interface for mta's, and trying to cater to everything else out there is asking fer coding nightmares. Notes: [1] Erm, whhen's this going to be out? What happened to 'Release early, release often?' I've had things I would have liked to have coded and submitted by now, but I've been holding off on fer nearly a month wating for the latest code. Mebbe we need stable/unstable tracks like the linux kernel? With unstable releases VERY often. -The Dragon De Monsyne From John@list.org Mon Jul 27 14:55:13 1998 From: John@list.org (John Viega) Date: Mon, 27 Jul 1998 06:55:13 -0700 Subject: [Mailman-Developers] an opinion about using port 25 In-Reply-To: ; from The Dragon De Monsyne on Mon, Jul 27, 1998 at 05:20:18AM -0500 References: <3272A6A6B51@power.feld.cvut.cz> Message-ID: <19980727065513.A3254@viega.org> On Mon, Jul 27, 1998 at 05:20:18AM -0500, The Dragon De Monsyne wrote: > > Notes: > [1] Erm, whhen's this going to be out? What happened to 'Release > early, release often?' I've had things I would have liked to have coded > and submitted by now, but I've been holding off on fer nearly a month > wating for the latest code. Mebbe we need stable/unstable tracks like the > linux kernel? With unstable releases VERY often. I almost resent this comment. I'd expect you to have a bit more consideration and tolerance. We said we'd *try* to release last week, and once we did, we'd release more often. However, we were not willing to release at all until we got something that worked for some reasonable value of working. Please also be considerate to the fact that we don't have as much time as we'd like to work on this project. I'm sorry if you feel frustrated; however, we have said in the past that we would provide you with a more current snapshot on request. I would not have refused any resonable request for a snapshot from someone interested in helping out. Some sort of private communication would have been a far more apropriate forum, until that avenue proved futile. From John@list.org Tue Jul 28 00:03:21 1998 From: John@list.org (John Viega) Date: Mon, 27 Jul 1998 16:03:21 -0700 Subject: [Mailman-Developers] Whoops Message-ID: <19980727160321.A9180@viega.org> Sorry if there were multiple autogened messages from me. I only meant to send the first; I forgot to change the target address before sending the rest. John From John@list.org Tue Jul 28 00:04:31 1998 From: John@list.org (John Viega) Date: Mon, 27 Jul 1998 16:04:31 -0700 Subject: [Mailman-Developers] Hmm... Message-ID: <19980727160431.A9200@viega.org> It seems none of those messages came through anyway. Anyway, if you do happen to see multiple messages, please disregard. From John Viega Tue Jul 28 00:13:08 1998 From: John Viega (John Viega) Date: Mon, 27 Jul 1998 16:13:08 -0700 Subject: [Mailman-Developers] ANNOUNCE: Mailman 1.0b5 released Message-ID: <19980727161308.A9289@viega.org> Well, for some reason the automated mail gets to me, but not to the list. But if I send mail to the list manually it goes right through. Since I don't have time to look at it, following is the announcement sent manually. Please forgive me if the autogenerated stuff eventually does show up. ANNOUNCE: Mailman 1.0b5 release Version 1.0b5 of the Mailman mailing list manager is now available from the Mailman web page: http://www.list.org/ Via ftp, the release is available at: ftp://www.list.org/pub/mailman/mailman-1.0b5.tar.gz New in this version: - New file locking that should be portable and work w/ NFS. - Better use of packages. - Better error logging and reporting. - Less startup overhead. - Various and sundry bug fixes. Please be sure to read the README file after downloading. John Viega From John@list.org Tue Jul 28 00:23:15 1998 From: John@list.org (John Viega) Date: Mon, 27 Jul 1998 16:23:15 -0700 Subject: [Mailman-Developers] Release stability Message-ID: <19980727162315.A9425@viega.org> We're going to try to test stuff as we release it. However, in these betas, we're not going to garuntee there isn't a major show-stopper. If someone finds one, let us know, and we'll put out a new release as soon as we fix it, now that there's a release tool. John From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Tue Jul 28 00:39:10 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 27 Jul 1998 19:39:10 -0400 (EDT) Subject: [Mailman-Developers] Release stability References: <19980727162315.A9425@viega.org> Message-ID: <13757.3998.707994.72844@anthem.cnri.reston.va.us> >>>>> "JV" == John Viega writes: JV> We're going to try to test stuff as we release it. However, JV> in these betas, we're not going to garuntee there isn't a JV> major show-stopper. JV> If someone finds one, let us know, and we'll put out a new JV> release as soon as we fix it, now that there's a release tool. I also hope to have public read-only CVS sources and CVSweb access available within the week, for those of you who like to stay on the bleeding edge. Stay tuned. -Barry From John@list.org Mon Jul 27 23:53:23 1998 From: John@list.org (John@list.org) Date: Mon, 27 Jul 1998 15:53:23 -0700 Subject: [Mailman-Developers] ANNOUNCE: Mailman 1.0b5 release Message-ID: <199807272253.PAA09076@lima.mudlib.org> Version 1.0b5 of the Mailman mailing list manager is now available from the Mailman web page: http://www.list.org/ Via ftp, the release is available at: ftp://www.list.org/pub/mailman/mailman-1.0b5.tar.gz New in this version: New in 1.0b5: - New file locking that should be portable and work w/ NFS. - Better use of packages. - Better error logging and reporting. - Less startup overhead. - Various and sundry bug fixes. 1.0b4 - A configure script for easy installation (Barry Warsaw) - The ability to install Mailman to locations other than /home/mailman (Barry Warsaw) - Use cookies on the admin pages (also hides admin pages from others) (Scott Cotton) - Subscription requests send a request for confirmation, which may be done by simply replying to the message (Scott Cotton) - Facilities for gating mail to a newsgroup, and for gating a newsgroup to a mailing list (John Viega) - Contact the SMTP port instead of calling sendmail (primarily for portability) (John Viega) - Changed all links on web pages to relative links where appropriate. (John Viega) - Use MD5 if crypt is not available (John Viega) - Lots of fixing up of bounce handling (Ken Manheimer) - General UI polishing (Ken Manheimer) - mm_html: Make it prominent when the user's delivery is disabled on his option page. (Ken Manheimer) - mallist:DeleteMember() Delete the option setings if any. (Ken Manheimer) DONE for mailman 1.0b3 1.0b3 (05/03/1998) All changes by klm@python.org (ken manheimer) Items marked by an '*' asterisk have greater operational impact. * mm_message:Deliverer.DeliverToList() added missing newline between the headers and message body. Without it, any sequence of initial body lines that _looked_ like headers ("Sir: Please excuse my impertinence, but") got treated like headers. * Fixed typo which broke subscription acknowledgement message (thanks to janne sinkonen for pointing this out promptly after release). (Anyone who applied my intermediate patch will probably see this one trigger patch'es reversed-patch detector...) * Fixed cgi-wrapper.c so it doesn't segfault when invoked with improper uid or gid, and generally wrappers are cleaned up a bit. * Prevented delivery-failure notices for misdirected subscribe- confirmation requests from bouncing back to the -request addr, and then being treated as failing requests. Implemented two measures. Set the reply-to for the confirmation- request to the -request addr, and the sender to be the list admin. This way, bounces go to list admin instead of to -request addr. (Using the errors-to header wasn't sufficient. Thanks, barry, for pointing out the use of sender here.) Second, ignore any mailcommands coming from postmaster or non-login system type accounts (mailer-daemon, daemon, postoffice, etc.) * Reenabled admin setting of web_page_url - crucial for having lists use alternate names of a host that occupies multiple addresses. * Fixed and refined admin-options help mechanism. Top-level visit to general-category (where the "general" isn't in the URL) was broken. New help presentation shows the same row that shows on the actual options page. * cron/crontab.in crontab template had wrong name for senddigests. * Default digest format setting, as distributed, is now non-MIME, on urging of reasoned voices asserting that there are still enough bad MIME implementations in the world to be a nuisance to too many users if MIME is the default. Sigh. * MIME digests now preserve the structure of MIME postings, keeping attachments as attachments, etc. They also are more structured in general. * Added README instructions explaining how to determine the right UID and GID settings for the wrapper executables, and improved some of the explanations about exploratory interaction w/mailman. * Removed the constraint that subscribers have their domain included in a static list in the code. We might want to eventually reincorporate the check for the sake of a warning message, to give a heads up to the subscriber, but try delivery anyway... - Added missing titles to error docs. - Improved several help details, including particularly explaining better how real_name setting is used. - Strengthened admonition against setting reply_goes_to_list. - Added X-BeenThere header to postings for the sake of prevention of external mail loops. - Improved handling of bounced messages to better recognize members address, and prevent duplicate attempts to react (which could cause superfluous notices to administrator). - Added __delitem__ method to mm_message.OutgoingMessage, to fix the intermediate patch posted just before this one. - Using keyword substitution format for more message text (ie, "substituting %(such)s into text" % {'such': "something"}) to make the substitutions less fragile and, presumably, easier to debug. - Removed hardwired (and failure-prone) /tmp file logging from answer.majordomo_mail, and generally spiffed up following janne sinkkonen's lead. 1.0b2 (04/13/1998) and 1.0b1.1 (04/09/1998): klm (ken manheimer) Web pages much more polished - Better organized, text more finely crafted - Easier, more refined layout - List info and admin interface overviews, enumerate all public lists (via, e.g., http://www.python.org/mailman/listinfo - sans the specific list) - Admin interface broken into sections, with help elaboration for complicated configuration options Maillist Archives - Integrated with a newer, *much* improved, external pipermail - to be found at http://starship.skyport.net/crew/amk/maintained/pipermail.html - Private archives protected with maillist members passwords, cookie-fied. Spam prevention - New spam prevention measures catch most if not all spam without operator intervention or general constraints on who can post to list: require_explicit_destination option imposes hold of any postings that do not have the list name in any of the to or cc header destination addresses. This catches the vast majority of random spam. Other options (forbidden_posters, bounce_matching_headers) provide for filtering of known transgressors. - Option obscure_addresses (default on) causes maillist subscriber lists on the web to be slightly mangled so they're not directly recognizable as email address by web spiders, which might be seeking targets for spammers. Site configuration arrangement organized - in mailman/mailman/modules: - When installing, create a mailman/modules/mm_cfg.py (if there's not one already there), using mm_cfg.py.dist as a template. mm_default.py contains the distributed defaults, including descriptions of the values. mm_cfg.py does a 'from mm_defaults.py import *' to get the distributed defaults. Include settings in mm_cfg.py for any values in mm_defaults.py that need to be customized for your site, after the 'from .. import *'. See mm_cfg.py.dist for more details. Logging - Major operations (subscription, admin approval, bounce, digestification, cgi script failure tracebacks) logged in files using a reliable mechanism - Wrapper executables log authentication complaints via syslog Wrappers - All cgi-script wrapper executables combined in a single source, easier to configure. (Mail and aliases wrappers separate.) List structure version migration - Provision for automatic update of list structures when moving to a new version of the system. See modules/versions.py. Code cleaning - Many more module docstrings, __version__ settings, more function docstrings. - Most unqualified exception catches have been replaced with more finely targeted catches, to avoid concealing bugs. - Lotsa long lines wrapped (pet peeve:). Random details (not complete, sorry): - make archival frequency a list option - Option for daily digest dispatch, in addition to size threshhold - make sure users only get one periodic password notifcation message for all the lists they're on (repaired 1.0b1.1 varying-case mistake) - Fix rmlist sans-argument bug causing deletion of all lists! - doubled generated random passwords to four letters - Cleaned lots and lots of notices - Lots and lots of html page cleanup, including table-of-contents, etc - Admin options sections - don't do the "if so" if the ensuing list is empty - Prevent list subject-prefix cascade - Sources under CVS - Various spam filters - implicit-destination, header-field - Adjusted permissions for group access - Prevent redundant subscription from redundant vetted requests - Instituted centralize, robustish logging - Wrapper sources use syslog for logging (john viega) - Sorting of users done on presentation, not in list. - Edit options - give an error for non-existent users, not an options page. - Bounce handling - offer 'disable' option, instead of remove, and never remove without notifying admin - Moved subscribers off of listinfo (and made private lists visible modulo authentication) - Parameterize default digest headers and footers and create some - Put titles on cgi result pages that do not get titles (all?) - Option for immediate admin notifcation via email of pending requests, as well as periodic - Admin options web-page help - Enabled grouped and cascading lists despite implicit-name constraint - Changed subscribers list so it has its own script (roster) - Welcome pages: http://www.python.org/mailman/{admin,listinfo}/ 0.95: (Jan 25, 1997) - Fixed a bug in sending out digests added when adding disable mime option. - Added an option to not notify about bounced posts. - Added hook for pre-posting filters. These could be used to auto-strip signatures. I'm using the feature to auto-strip footers that are auto-generated by mail received from another mailing list. 0.94: (Jan 22, 1997) - Made admin password work ubiquitously in place of a user password. - Added an interface for getting / setting user options. - Added user option to disable mime digests (digested people only) - Added user option to not receive your own posts (nondigested people only) - Added user option to ack posts - Added user option to disable list delivery to their box. - Added web interface to user options - Config number of sendmail spawns on a per-list basis - Fixed extra space at beginning of each message in digests... - Handled comma separated emails in bounce messages... - Added a FindUser() function to MailList. Used it where appropriate. - Added mail interface to setting list options. - Added name links to the templates options page - Added an option so people can hide their names from the subscription list. - Added an answer_majordomo_mail script for people switching... 0.93: (Jan 18,20 1997) - When delivering to list, don't call sendmail directly. Write to a file, and then run the new deliver script, which forks and exits in the parent immediately to avoid hanging when delivering mail for large lists, so that large lists don't spend a lot of time locked. - GetSender() no longer assumes that you don't have an owner-xxx address. - Fixed unsubscribing via mail. - Made subscribe via mail generate a password if you don't supply one. - Added an option to clobber the date in the archives to the date the list resent the post, so that the archive doesn't get mail from people sending bad dates clumped up at the beginning or end. - Added automatic error message processing as an option. Currently logging to /tmp/bounce.log - Changed archive to take a list as an argument, (the old way was broken) - Remove (ignore) spaces in email addresses - Allow user passwords to be case insensitive. - Removed the cleanup script since it was now redundant. - Fixed archives if there were no archives. - Added a Lock() call to Load() and Create(). This fixes the problem of loading then locking. - Removed all occurances of Lock() except for the ones in maillist since creating a list now implicitly locks it. - Quote single periods in message text. - Made bounce system handle digest users fairly. 0.92: (Jan 13-16 1997) - Added Lock and Unlock methods to list to ensure each operation is atomic - Added a cmd that rms all files of a mailing list (but not the aliases) - Fixed subscribing an unknown user@localhost (confirm this) - Changed the sender to list-admin@... to ensure we avoid mail loops. - check to make sure there are msgs to archive before calling pipermail. - started using this w/ real mailing lists. - Added a cron script that scours the maillog for User/Host unknown errs - Sort membership lists - Always display digest_is_default option - Don't slam the TO list unless you're sending a digest. - When making digest summaries, if missing sender name, use their email. - Hacked in some protection against crappy dates in pipermail.py - Made it so archive/digest volumes can go up monthly for large large lists. - Number digest messages - Add headers/footers to each message in digest for braindead mailers - I removed some forgotten debug statements that caused server errors when a CGI script sent mail. - Removed loose_matches flag, since everything used it. - Fixed a problem in pipermail if there was no From line. - In upvolume_ scripts, remove INDEX files as we leave a volume. - Threw a couple of scripts in bin for generating archives from majordomo's digest-archives. I wouldn't recommend them for the layman, though, they were meant to do a job quickly, not to be usable. 0.91: (Dec 23 1996) - broke code into mixins for managability - tag parsing instead of lots of gsubs - tweaked pipermail (see comments on pipermail header) - templates are now on a per-list basis as intended. - request over web that your password be emailed to you. - option so that web subscriptions require email confirmation. - wrote a first pass at an admin interface to configurable variables. - made digests mime-compliant. - added a FakeFile class that simulates enough of a file object on a string of text to fool rfc822.Message in non-seek mode. - changed OutgoingMessage not to require its args in constructor. - added an admin request DB interface. - clearly separated the internal name from the real name. - replaced lots of ugly, redundant code w/ nice code. (added Get...Email() interfaces, GetScriptURL, etc...) - Wrote a lot of pretty html formatting functions / classes. (Dec 27 1997) - Fleshed out the newlist command a lot. It now mails the new list admin, and auto-updates the aliases file. - Made multiple owners acceptable. - Non-advertised lists, closed lists, max header length, max msg length - Allowed editing templates from list admin pages. - You can get to your info page from the web even if the list is closed. Please be sure to read the README file after downloading. John Viega From cklempay@acm.jhu.edu Wed Jul 29 14:37:25 1998 From: cklempay@acm.jhu.edu (Corbett J. Klempay) Date: Wed, 29 Jul 1998 09:37:25 -0400 (EDT) Subject: [Mailman-Developers] mmsitepass puking Message-ID: I just upgraded a 1.0b4 --> 1.0b5...when I tried to run mmsitepass (didn't know if I needed to do this again since I was upgrading, but figured it would be better to be safe than sorry...)...and I got this: [root@chimera bin]# mmsitepass snoop Traceback (innermost last): File "./mmsitepass", line 27, in ? from Mailman import MailList File "/home/mailman/Mailman/MailList.py", line 40, in ? from SecurityManager import SecurityManager File "/home/mailman/Mailman/SecurityManager.py", line 24, in ? import Crypt File "/home/mailman/Mailman/Crypt.py", line 19, in ? if mm_cfg.USE_CRYPT: AttributeError: USE_CRYPT [root@chimera bin]# Then, when I tried to look at www2.acm.jhu.edu/mailman/listinfo, I got an internal server error, with this in /var/log/httpd/error_log: [Wed Jul 29 09:27:04 1998] access to /home/mailman/cgi-bin/listinfo failed for 1 28.220.223.50, reason: Premature end of script headers ...and while I was writing this message, I postponed it to investigate something else...I'm now getting this message every 5 minutes from the Cron Daemon: Traceback (innermost last): File "/home/mailman/cron/gate_news", line 22, in ? from Mailman import MailList File "/home/mailman/Mailman/MailList.py", line 40, in ? from SecurityManager import SecurityManager File "/home/mailman/Mailman/SecurityManager.py", line 24, in ? import Crypt File "/home/mailman/Mailman/Crypt.py", line 19, in ? if mm_cfg.USE_CRYPT: AttributeError: USE_CRYPT I tried sending a test message to one of the lists I host..haven't seen it yet (10 minutes ago, so I'm assuming it's not coming). BTW - Kudos to whoever added in the permissions checking in configure! ------------------------------------------------------------------------------- Corbett J. Klempay Quote of the Week: http://www2.acm.jhu.edu/~cklempay "Talent develops in quiet places, character in the full current of human life." PGP Fingerprint: 7DA2 DB6E 7F5E 8973 A8E7 347B 2429 7728 76C2 BEA1 ------------------------------------------------------------------------------- From John@list.org Wed Jul 29 14:31:48 1998 From: John@list.org (John Viega) Date: Wed, 29 Jul 1998 06:31:48 -0700 Subject: [Mailman-Developers] mmsitepass puking In-Reply-To: ; from Corbett J. Klempay on Wed, Jul 29, 1998 at 09:37:25AM -0400 References: Message-ID: <19980729063148.A29993@viega.org> Oh, hmm. We really need to be tracking new variables in the config file. Just throw USE_CRYPT=1 into your mm_cfg.py. Then, if you're interested, diff your old defaults with the one that comes w/ the b5 dist and let us know what else is missing. John On Wed, Jul 29, 1998 at 09:37:25AM -0400, Corbett J. Klempay wrote: > I just upgraded a 1.0b4 --> 1.0b5...when I tried to run mmsitepass (didn't > know if I needed to do this again since I was upgrading, but figured it > would be better to be safe than sorry...)...and I got this: > > [root@chimera bin]# mmsitepass snoop > Traceback (innermost last): > File "./mmsitepass", line 27, in ? > from Mailman import MailList > File "/home/mailman/Mailman/MailList.py", line 40, in ? > from SecurityManager import SecurityManager > File "/home/mailman/Mailman/SecurityManager.py", line 24, in ? > import Crypt > File "/home/mailman/Mailman/Crypt.py", line 19, in ? > if mm_cfg.USE_CRYPT: > AttributeError: USE_CRYPT > [root@chimera bin]# > > Then, when I tried to look at www2.acm.jhu.edu/mailman/listinfo, I got an > internal server error, with this in /var/log/httpd/error_log: > > [Wed Jul 29 09:27:04 1998] access to /home/mailman/cgi-bin/listinfo failed > for 1 > 28.220.223.50, reason: Premature end of script headers > > ..and while I was writing this message, I postponed it to investigate > something else...I'm now getting this message every 5 minutes from the > Cron Daemon: > > Traceback (innermost last): > File "/home/mailman/cron/gate_news", line 22, in ? > from Mailman import MailList > File "/home/mailman/Mailman/MailList.py", line 40, in ? > from SecurityManager import SecurityManager > File "/home/mailman/Mailman/SecurityManager.py", line 24, in ? > import Crypt > File "/home/mailman/Mailman/Crypt.py", line 19, in ? > if mm_cfg.USE_CRYPT: > AttributeError: USE_CRYPT > > I tried sending a test message to one of the lists I host..haven't seen it > yet (10 minutes ago, so I'm assuming it's not coming). > > BTW - Kudos to whoever added in the permissions checking in configure! > > ------------------------------------------------------------------------------- > Corbett J. Klempay Quote of the Week: > http://www2.acm.jhu.edu/~cklempay "Talent develops in quiet places, > character in the full current of > human life." > > PGP Fingerprint: 7DA2 DB6E 7F5E 8973 A8E7 347B 2429 7728 76C2 BEA1 > ------------------------------------------------------------------------------- > > > > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers From cklempay@acm.jhu.edu Wed Jul 29 14:58:50 1998 From: cklempay@acm.jhu.edu (Corbett J. Klempay) Date: Wed, 29 Jul 1998 09:58:50 -0400 (EDT) Subject: [Mailman-Developers] more stuff, it seems... Message-ID: I made the USE_CRYPT = 1 change...and now the 5 minute cron gives me: Date: Wed, 29 Jul 1998 09:55:02 -0400 From: Cron Daemon To: mailman@chimera.acm.jhu.edu Subject: Cron /usr/bin/python /home/mailman/cron/gate_news Traceback (innermost last): File "/home/mailman/cron/gate_news", line 45, in ? list = MailList.MailList(name, lock=0) File "/home/mailman/Mailman/MailList.py", line 60, in __init__ self.Load() File "/home/mailman/Mailman/MailList.py", line 587, in Load self.CheckVersion(dict) File "/home/mailman/Mailman/MailList.py", line 602, in CheckVersion if (self.data_version >= mm_cfg.DATA_FILE_VERSION and AttributeError: DATA_FILE_VERSION Traceback (innermost last): File "/home/mailman/cron/gate_news", line 45, in ? list = MailList.MailList(name, lock=0) File "/home/mailman/Mailman/MailList.py", line 60, in __init__ self.Load() File "/home/mailman/Mailman/MailList.py", line 587, in Load self.CheckVersion(dict) File "/home/mailman/Mailman/MailList.py", line 602, in CheckVersion if (self.data_version >= mm_cfg.DATA_FILE_VERSION and AttributeError: DATA_FILE_VERSION Traceback (innermost last): File "/home/mailman/cron/gate_news", line 45, in ? list = MailList.MailList(name, lock=0) File "/home/mailman/Mailman/MailList.py", line 60, in __init__ self.Load() File "/home/mailman/Mailman/MailList.py", line 587, in Load Traceback (innermost last): File "/home/mailman/cron/gate_news", line 45, in ? list = MailList.MailList(name, lock=0) File "/home/mailman/Mailman/MailList.py", line 60, in __init__ self.Load() File "/home/mailman/Mailman/MailList.py", line 587, in Load self.CheckVersion(dict) File "/home/mailman/Mailman/MailList.py", line 602, in CheckVersion if (self.data_version >= mm_cfg.DATA_FILE_VERSION and AttributeError: DATA_FILE_VERSION self.CheckVersion(dict) File "/home/mailman/Mailman/MailList.py", line 602, in CheckVersion if (self.data_version >= mm_cfg.DATA_FILE_VERSION and AttributeError: DATA_FILE_VERSION John: I have zero diff experience...if you gave me a command line or something, I'd run it (or whatever else) for ya if you need...I just don't want to horse around with it for a long time when a) I'm not sure if I'd be using it right and b) I'm at my new internship and am sneaking out through the corporate firewall to get here :) ------------------------------------------------------------------------------- Corbett J. Klempay Quote of the Week: http://www2.acm.jhu.edu/~cklempay "Talent develops in quiet places, character in the full current of human life." PGP Fingerprint: 7DA2 DB6E 7F5E 8973 A8E7 347B 2429 7728 76C2 BEA1 ------------------------------------------------------------------------------- From John@list.org Wed Jul 29 14:56:25 1998 From: John@list.org (John Viega) Date: Wed, 29 Jul 1998 06:56:25 -0700 Subject: [Mailman-Developers] more stuff, it seems... In-Reply-To: ; from Corbett J. Klempay on Wed, Jul 29, 1998 at 09:58:50AM -0400 References: Message-ID: <19980729065625.A30183@viega.org> Try: diff ~//Defaults.py.in mm_defaults.py (Wasn't it mm_defaults in B4? Whatever your current default file is.) It'll show all differences, including ones where the option is in both files, but just changed. For things other than USE_CRYPT, I suggest just copying the missing items over. Please let us know what they are... John On Wed, Jul 29, 1998 at 09:58:50AM -0400, Corbett J. Klempay wrote: > I made the USE_CRYPT = 1 change...and now the 5 minute cron gives me: > > Date: Wed, 29 Jul 1998 09:55:02 -0400 > From: Cron Daemon > To: mailman@chimera.acm.jhu.edu > Subject: Cron /usr/bin/python > /home/mailman/cron/gate_news > > Traceback (innermost last): > File "/home/mailman/cron/gate_news", line 45, in ? > list = MailList.MailList(name, lock=0) > File "/home/mailman/Mailman/MailList.py", line 60, in __init__ > self.Load() > File "/home/mailman/Mailman/MailList.py", line 587, in Load > self.CheckVersion(dict) > File "/home/mailman/Mailman/MailList.py", line 602, in CheckVersion > if (self.data_version >= mm_cfg.DATA_FILE_VERSION and > AttributeError: DATA_FILE_VERSION > Traceback (innermost last): > File "/home/mailman/cron/gate_news", line 45, in ? > list = MailList.MailList(name, lock=0) > File "/home/mailman/Mailman/MailList.py", line 60, in __init__ > self.Load() > File "/home/mailman/Mailman/MailList.py", line 587, in Load > self.CheckVersion(dict) > File "/home/mailman/Mailman/MailList.py", line 602, in CheckVersion > if (self.data_version >= mm_cfg.DATA_FILE_VERSION and > AttributeError: DATA_FILE_VERSION > Traceback (innermost last): > File "/home/mailman/cron/gate_news", line 45, in ? > list = MailList.MailList(name, lock=0) > File "/home/mailman/Mailman/MailList.py", line 60, in __init__ > self.Load() > File "/home/mailman/Mailman/MailList.py", line 587, in Load > Traceback (innermost last): > File "/home/mailman/cron/gate_news", line 45, in ? > list = MailList.MailList(name, lock=0) > File "/home/mailman/Mailman/MailList.py", line 60, in __init__ > self.Load() > File "/home/mailman/Mailman/MailList.py", line 587, in Load > self.CheckVersion(dict) > File "/home/mailman/Mailman/MailList.py", line 602, in CheckVersion > if (self.data_version >= mm_cfg.DATA_FILE_VERSION and > AttributeError: DATA_FILE_VERSION > self.CheckVersion(dict) > File "/home/mailman/Mailman/MailList.py", line 602, in CheckVersion > if (self.data_version >= mm_cfg.DATA_FILE_VERSION and > AttributeError: DATA_FILE_VERSION > > John: I have zero diff experience...if you gave me a command line or > something, I'd run it (or whatever else) for ya if you need...I just don't > want to horse around with it for a long time when a) I'm not sure if I'd > be using it right and b) I'm at my new internship and am sneaking out > through the corporate firewall to get here :) > > ------------------------------------------------------------------------------- > Corbett J. Klempay Quote of the Week: > http://www2.acm.jhu.edu/~cklempay "Talent develops in quiet places, > character in the full current of > human life." > > PGP Fingerprint: 7DA2 DB6E 7F5E 8973 A8E7 347B 2429 7728 76C2 BEA1 > ------------------------------------------------------------------------------- > > > > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers From cklempay@acm.jhu.edu Wed Jul 29 15:12:08 1998 From: cklempay@acm.jhu.edu (Corbett J. Klempay) Date: Wed, 29 Jul 1998 10:12:08 -0400 (EDT) Subject: [Mailman-Developers] The diffs Message-ID: Here's what diff spit out when I did: diff Defaults.py mm_defaults.py ---- 19c19 < """Distributed default settings for significant Mailman config variables. --- > """Distributed default settings for significant mailman config variables. 47,52d46 < # 1 to use crypt for passwords instead of md5. < # Crypt may not work on all python installs. < # Don't change this value once you have lists running... < # In fact, you should just let configure set this one and leave it alone. < USE_CRYPT = 1 < 86,92d79 < # This variable controlls whether monthly password reminders are sent. < DEFAULT_SEND_REMINDERS = 1 < # Send welcome messages to new users? Probably should keep this set to 1. < DEFAULT_SEND_WELCOME_MSG = 1 < # Wipe sender information, and make it look like the list-admin < # address sends all messages < DEFAULT_ANONYMOUS_LIST = 0 128,130c115,122 < DEFAULT_PLAIN_DIGEST_KEEP_HEADERS = ['message', 'date', 'from', < 'subject', 'to', 'cc', < 'reply-to', 'organization'] --- > # We're only retaining the text file, an external pipermail (andrew's > # newest version) is pointed at the retained text copies. > ## # 0 = never, 1 = daily, 2 = hourly: > ## DEFAULT_ARCHIVE_UPDATE_FREQUENCY = 2 > ## # 0 = yearly, 1 = monthly > ## DEFAULT_ARCHIVE_VOLUME_FREQUENCY = 0 > ## # Retain a flat text mailbox of postings as well as the fancy archives? > ## DEFAULT_ARCHIVE_RETAIN_TEXT_COPY = 1 152a145,165 > # Enumeration for types of configurable variables in Mailman. > Toggle = 1 > Radio = 2 > String = 3 > Text = 4 > Email = 5 > EmailList = 6 > Host = 7 > Number = 8 > > # could add Directory and URL > > > # Bitfield for user options > Digests = 0 # handled by other mechanism, doesn't need a flag. > DisableDelivery = 1 > DontReceiveOwnPosts = 2 # Non-digesters only > AcknowlegePosts = 4 > DisableMime = 8 # Digesters only > ConcealSubscription = 16 > 170c183 < PYTHON = '/usr/local/bin/python' --- > PYTHON = '/usr/bin/python' 178,202d190 < # Don't change anything from here down unless you know what you're doing... < < < # Enumeration for types of configurable variables in Mailman. < Toggle = 1 < Radio = 2 < String = 3 < Text = 4 < Email = 5 < EmailList = 6 < Host = 7 < Number = 8 < < # could add Directory and URL < < < # Bitfield for user options < Digests = 0 # handled by other mechanism, doesn't need a flag. < DisableDelivery = 1 < DontReceiveOwnPosts = 2 # Non-digesters only < AcknowlegePosts = 4 < DisableMime = 8 # Digesters only < ConcealSubscription = 16 < < 216,219c204 < VERSION = '1.0b5' < < # Data file version number < DATA_FILE_VERSION = 3 --- > VERSION = '1.0b4' --- ------------------------------------------------------------------------------- Corbett J. Klempay Quote of the Week: http://www2.acm.jhu.edu/~cklempay "Talent develops in quiet places, character in the full current of human life." PGP Fingerprint: 7DA2 DB6E 7F5E 8973 A8E7 347B 2429 7728 76C2 BEA1 ------------------------------------------------------------------------------- From John@list.org Wed Jul 29 15:09:20 1998 From: John@list.org (John Viega) Date: Wed, 29 Jul 1998 07:09:20 -0700 Subject: [Mailman-Developers] The diffs In-Reply-To: ; from Corbett J. Klempay on Wed, Jul 29, 1998 at 10:12:08AM -0400 References: Message-ID: <19980729070920.C30183@viega.org> On Wed, Jul 29, 1998 at 10:12:08AM -0400, Corbett J. Klempay wrote: Add the following stuff: # This variable controlls whether monthly password reminders are sent. DEFAULT_SEND_REMINDERS = 1 # Send welcome messages to new users? Probably should keep this set to 1. DEFAULT_SEND_WELCOME_MSG = 1 # Wipe sender information, and make it look like the list-admin # address sends all messages DEFAULT_ANONYMOUS_LIST = 0 DEFAULT_PLAIN_DIGEST_KEEP_HEADERS = ['message', 'date', 'from', 'subject', 'to', 'cc', 'reply-to', 'organization'] # Data file version number DATA_FILE_VERSION = 3 From John@list.org Wed Jul 29 15:20:19 1998 From: John@list.org (John Viega) Date: Wed, 29 Jul 1998 07:20:19 -0700 Subject: [Mailman-Developers] The diffs In-Reply-To: ; from Corbett J. Klempay on Wed, Jul 29, 1998 at 10:12:08AM -0400 References: Message-ID: <19980729072019.D30183@viega.org> I realized that the real problem is the name change. Just change the import in mm_cfg.py to Defaults from mm_defaults, and that should have the same effect as adding those lines. John From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Wed Jul 29 15:44:45 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 29 Jul 1998 10:44:45 -0400 (EDT) Subject: [Mailman-Developers] The diffs References: <19980729072019.D30183@viega.org> Message-ID: <13759.13661.65610.200383@anthem.cnri.reston.va.us> >>>>> "JV" == John Viega writes: JV> I realized that the real problem is the name change. Just JV> change the import in mm_cfg.py to Defaults from mm_defaults, JV> and that should have the same effect as adding those lines. Right, dang. We should have included that in the release notes. John, do you think you can start a 1.0b5 release note/patch page off of list.org? -Barry From cklempay@acm.jhu.edu Wed Jul 29 16:04:53 1998 From: cklempay@acm.jhu.edu (Corbett J. Klempay) Date: Wed, 29 Jul 1998 11:04:53 -0400 (EDT) Subject: [Mailman-Developers] Oddities Message-ID: Well, I left those settings in mm_cfy.py that I copied in, and ended up also changing the import to have it import from Defaults.py (so I guess that's redundant, but it shouldn't hurt anything, eh?). Anyway, the annoying 5 minute cron messages have stopped...so I guess that part is kosher now. However two problems remain: - Test messages sent to one of the lists from my previous 1.0b4 install are just getting swallowed up and never getting sent to the list - Going to www2.acm.jhu.edu/mailman/listinfo still gives an Internal Server Error...and the /var/log/httpd/error_log file lists this at the end: [Wed Jul 29 10:43:32 1998] access to /home/mailman/cgi-bin/listinfo failed for 1 28.220.223.50, reason: Premature end of script headers Any ideas? ------------------------------------------------------------------------------- Corbett J. Klempay Quote of the Week: http://www2.acm.jhu.edu/~cklempay "Talent develops in quiet places, character in the full current of human life." PGP Fingerprint: 7DA2 DB6E 7F5E 8973 A8E7 347B 2429 7728 76C2 BEA1 ------------------------------------------------------------------------------- From cklempay@acm.jhu.edu Wed Jul 29 16:08:19 1998 From: cklempay@acm.jhu.edu (Corbett J. Klempay) Date: Wed, 29 Jul 1998 11:08:19 -0400 (EDT) Subject: [Mailman-Developers] hehe...typo Message-ID: Just to clear any confusion, I of course meant mm_cfg.py in that first line of the last message... :) ------------------------------------------------------------------------------- Corbett J. Klempay Quote of the Week: http://www2.acm.jhu.edu/~cklempay "Talent develops in quiet places, character in the full current of human life." PGP Fingerprint: 7DA2 DB6E 7F5E 8973 A8E7 347B 2429 7728 76C2 BEA1 ------------------------------------------------------------------------------- From cklempay@acm.jhu.edu Thu Jul 30 17:50:23 1998 From: cklempay@acm.jhu.edu (Corbett J. Klempay) Date: Thu, 30 Jul 1998 12:50:23 -0400 (EDT) Subject: [Mailman-Developers] Anyone else seeing this? Message-ID: Ok, this is really 2 messages chained together...it seems John is soon to be a dad (or maybe a dad again, not sure actually :), so he's a little busy :) Any assistance is _greatly_ appreciated...the other ACM guys kept whining because the list is down, so I just set up a temp alias to quiet them until I get this sorted out :) --- Is it supposed to be the case where you have to be root to create a new list? I thought that in my 1.0b4 install, I had created new lists as cklempay...but if I do it as anything other than root now (with b5), I get this: [mailman@chimera bin]$ newlist test Enter the email of the person running the list: cklempay@acm.jhu.edu Enter the initial list password: snoop Traceback (innermost last): File "/home/mailman/bin/newlist", line 133, in ? raise SystemExit(main(sys.argv)) File "/home/mailman/bin/newlist", line 83, in main newlist.Create(list_name, owner_mail, pw) File "/home/mailman/Mailman/MailList.py", line 518, in Create Utils.MakeDirTree(os.path.join(mm_cfg.LIST_DATA_DIR, name)) File "/home/mailman/Mailman/Utils.py", line 276, in MakeDirTree os.mkdir(made_part, perms) os.error: (13, 'Permission denied') [mailman@chimera bin]$ I don't know if this is the way it is supposed to be and maybe I had it working before only because maybe I had messed up some permissions... I had been having a LOT of problems getting it to let me access any of the pages (all of the logs turned up 'Premature end of script headers' or in some configurations I'd get a Internal Server Error). In my current state, I can view www2.acm.jhu.edu/mailman/listinfo but if I su to root and do a newlist to create a test list, I get this if I try to access www2.acm.jhu.edu/mailman/admin/test : 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: Content-type: text/html We're sorry, we hit a bug! Mailman experienced a very low level failure and could not even generate a useful traceback. Please report this to the Mailman administrator at this site. I'm not sure, but I thought I remembered someone mentioning something like this earlier today too. One other quick (and sort of unrelated question)...I just recursively zipped up my /home/mailman/lists subtree before killing b4...since my aliases are still in place (didn't touch those), can I just extract them to their original places and have it work? Or does Mailman keep other administrative data about that it won't have for these lists if I create them that way? ---next msg---- From CorbettJ.Klempay Thu Jul 30 17:04:20 1998 From: CorbettJ.Klempay (CorbettJ.Klempay) Date: Thu, 30 Jul 1998 12:04:20 -0400 (EDT) Subject: Cron /usr/bin/python /home/mailman/cron/senddigests (fwd) I am getting this as well...I followed the permissions stuff to the letter...? ---------- Forwarded message ---------- Date: Thu, 30 Jul 1998 12:00:00 -0400 From: Cron Daemon To: mailman@chimera.acm.jhu.edu Subject: Cron /usr/bin/python /home/mailman/cron/senddigests Traceback (innermost last): File "/home/mailman/cron/senddigests", line 37, in ? main() File "/home/mailman/cron/senddigests", line 31, in main list = MailList.MailList(name, lock=0) File "/home/mailman/Mailman/MailList.py", line 60, in __init__ self.Load() File "/home/mailman/Mailman/MailList.py", line 587, in Load self.CheckVersion(dict) File "/home/mailman/Mailman/MailList.py", line 611, in CheckVersion self.Save() File "/home/mailman/Mailman/MailList.py", line 558, in Save os.link(fname, fname_last) os.error: (13, 'Permission denied') ---end #2 ------------------------------------------------------------------------------- Corbett J. Klempay Quote of the Week: http://www2.acm.jhu.edu/~cklempay "Talent develops in quiet places, character in the full current of human life." PGP Fingerprint: 7DA2 DB6E 7F5E 8973 A8E7 347B 2429 7728 76C2 BEA1 ------------------------------------------------------------------------------- From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Thu Jul 30 19:59:40 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 30 Jul 1998 14:59:40 -0400 (EDT) Subject: [Mailman-Developers] Anyone else seeing this? References: Message-ID: <13760.49820.31602.245524@anthem.cnri.reston.va.us> Corbett, I suspect all your problems are related to permission or ownership problems. You installed 1.0b5 on top of an earlier installation didn't you? Earlier versions weren't quite as strict on perm/ownership (esp. group ownership) as 1.0b5 -- but they had other problems. BTW, you followed the README note about moving your list template files right? Please look at your installed directory (e.g. $prefix). You want to make sure all the files are group owned by the `mailman' group, and that all directories and files are writeable by group. Further, be sure that all directories have the group sticky bit set (so new files will inherit the right group owner). You want to in particular, make sure lists/yourlist/config.db is group writeable, etc. If all that looks okay, but still doesn't work, then I might suggest trying to re-install Mailman 1.0b5 into a fresh location. Re-run configure with a different --prefix. Once you've done the new install, try creating a test list under the new location (you might need to set up your Web server to include a second ScriptAlias). If this test list works, then you should be able to copy your existing list subdirs to the new location (again, watching very carefully group write permission and ownership). Now your old lists should work from your new URLs. -Barry From cklempay@acm.jhu.edu Thu Jul 30 20:27:56 1998 From: cklempay@acm.jhu.edu (Corbett J. Klempay) Date: Thu, 30 Jul 1998 15:27:56 -0400 (EDT) Subject: [Mailman-Developers] Anyone else seeing this? In-Reply-To: <13760.49820.31602.245524@anthem.cnri.reston.va.us> Message-ID: > > Corbett, > > I suspect all your problems are related to permission or ownership > problems. You installed 1.0b5 on top of an earlier installation > didn't you? Earlier versions weren't quite as strict on > perm/ownership (esp. group ownership) as 1.0b5 -- but they had > other problems. BTW, you followed the README note about moving your > list template files right? > Yeah, I thought that the install over was maybe causing me some headaches...so I did a nice rm -rf on my mailman dir and killed the user, and started over from scratch. All of the reported problems (from the previous posting) were encountered from this clean 1.0b5 install. > Please look at your installed directory (e.g. $prefix). You want to > make sure all the files are group owned by the `mailman' group, and > that all directories and files are writeable by group. Further, be > sure that all directories have the group sticky bit set (so new files > will inherit the right group owner). Yeah, they appeared to be...and to make sure, I just went to /home and did chmod -R g+w mailman chmod -R g+s mailman After doing this, I pointed Netscape at http://www2.acm.jhu.edu/mailman/listinfo (as well as www2.acm.jhu.edu/mailman/listinfo/test -- I created this list as per the install)...and both gave me this now-familiar page: 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: Content-type: text/html We're sorry, we hit a bug! Mailman experienced a very low level failure and could not even generate a useful traceback. Please report this to the Mailman administrator at this site. > > You want to in particular, make sure lists/yourlist/config.db is group > writeable, etc. > I killed my b4 install, but before I did, I recursively zipped up my lists subtree. So are you saying that as long as the permissions on them are right, I can just unzip them back to their place and my old lists will live once again? (all of the aliases are still active from them) I haven't tried this yet...(as I was trying to sort of these regular problems first) Just in case you spot anything odd, I'm going to send my ls -l -R /home/mailman your way (just to you...don't want to spam the list with that...) CK From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Thu Jul 30 21:24:51 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 30 Jul 1998 16:24:51 -0400 (EDT) Subject: [Mailman-Developers] Anyone else seeing this? References: <13760.49820.31602.245524@anthem.cnri.reston.va.us> Message-ID: <13760.54931.368574.994944@anthem.cnri.reston.va.us> --M7zH6CPYdt Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Corbett, Everything looks okay to me, and I just did a fresh install, as root, from the 1.0b5 tarball. Then I created a dummy list and had no problem viewing the list-of-lists and the specific list info page. Note that I am running this in a Solaris 2.6 system, what OS are you using? We've had one other report of something similar happening on Linux (so I wonder if some OS problem could happening). Since I can't reproduce the problem on my end, I'm going to need your help. We have trace through the driver script to see where it's crapping out. Here's a version that does some very simple print-style tracing to /tmp/mailman.log. Can you substitute this for scripts/driver and see if it gives you a clue as to what is failing? -Barry --M7zH6CPYdt Content-Type: text/plain Content-Description: test driver script Content-Disposition: inline; filename="driver" Content-Transfer-Encoding: 7bit #! /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. # Useful for debugging. When an error occurs, this attaches the file name to # the exception string and re-raises (using the bogus Python 1.5 semantics) # this may be unnecessary in Python 1.5.2 ## realopen = open ## def open(filename, mode='r', bufsize=-1, realopen=realopen): ## try: ## return realopen(filename, mode, bufsize) ## except IOError, e: ## strerror = e.strerror + ': ' + filename ## e.strerror = strerror ## e.args = (e.args[0], strerror) ## # Python 1.5 ## import sys ## raise e, None, sys.exc_info()[2] ## # Python 1.5.1 ## #raise ## import __builtin__ ## __builtin__.__dict__['open'] = open # This standard driver script is used to run CGI programs, wrapped in code # that catches errors, and displays them as HTML. This guarantees that # (almost) any problems in the Mailman software doesn't result in a Web server # error. It is much more helpful to generate and show a traceback, which the # user could send to the administrator, than to display a server error and # have to trudge through server logs. # Note: this isn't 100% perfect! Here are some things that can go wrong that # are not caught and reported as traceback-containing HTML: # # - This file could contain a syntax error. In that case, you would indeed # get a Web server error since this file wouldn't even compile, and there's # no way to catch that. # # - The sys module could be royally screwed. Either we couldn't import it, or # it didn't have a sys.stderr attribute. Both those would indicate serious # problems in the Python installation. These won't generate Web server # errors, but neither will they give meaningful tracebacks. # # - We couldn't import the traceback module, or traceback.print_exc() # failed. Same diagnosis and effect as with sys being broken. # # I consider all these pretty unlikely. Note that it is also possible that # the environment variables wouldn't be printed, perhaps because os couldn't # be imported or there was some problem with os.environ. Again, not likely. def run_main(): try: # insert the relative path to the parent of the Mailman package # directory, so we can pick up the Utils module fp.write('import os\n') import os # sys gets imported at module level below fp.write('sys.path.insert()\n') sys.path.insert(0, os.pardir) # map stderr to a logger, if possible fp.write('import StampedLogger\n') from Mailman.Logging.StampedLogger import StampedLogger fp.write('import MultiLogger\n') from Mailman.Logging.MultiLogger import MultiLogger fp.write('instantiating logger\n') logger = StampedLogger('error', label='admin', manual_reprime=1, nofail=0) fp.write('instantiating multi\n') multi = MultiLogger(sys.__stdout__, logger) # The name of the module to run is passed in argv[1]. What we # actually do is import the module named by argv[1] that lives in the # Mailman.Cgi package. That module must have a main() function, which # we dig out and call. # fp.write('should now get normal error reporting\n') scriptname = sys.argv[1] # See the reference manual for why we have to do things this way. # Note that importing should have no side-effects! pkg = __import__('Mailman.Cgi', globals(), locals(), [scriptname]) module = getattr(pkg, scriptname) main = getattr(module, 'main') try: main() except SystemExit: # this is a valid way for the function to exit pass except: print_traceback(logger, multi) print_environment(logger) def print_traceback(logger, multi): print """\ Content-type: text/html

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:

"""
    logger.write('[----- Traceback ------]\n')
    try:
        import traceback
        # in normal situation, this will get logged to the MultiLogger created
        # above, which will write the data to both the real live stdout, and
        # the StampedLogger
        traceback.print_exc(file=multi)
    except:
        multi.write('[failed to get a traceback]\n')
    print '\n\n
' def print_environment(logger): try: import os print '''\

Environment variables:

''' logger.write('[----- Environment Variables -----]\n') for varname, value in os.environ.items(): print '' logger.write('\t%s: %s\n' % (varname, value)) print '
Variable Value
', varname, '', value, '
' except: print '

[environment variables are not available]' try: fp = open('/tmp/mailman.log', 'w+') fp.write('=====\nimport sys\n') import sys try: fp.write('run_main()\n') run_main() fp.write('done.\n') finally: # this is probably not strictly necessary since the script is exiting # soon anyway sys.stderr = sys.__stderr__ except: # Jeez, we couldn't even import sys, or sys didn't have a stderr # attribute! print """\ Content-type: text/html

We're sorry, we hit a bug!

Mailman experienced a very low level failure and could not even generate a useful traceback. Please report this to the Mailman administrator at this site. """ --M7zH6CPYdt-- From cklempay@acm.jhu.edu Thu Jul 30 22:24:28 1998 From: cklempay@acm.jhu.edu (Corbett J. Klempay) Date: Thu, 30 Jul 1998 17:24:28 -0400 (EDT) Subject: [Mailman-Developers] Anyone else seeing this? In-Reply-To: <13760.54931.368574.994944@anthem.cnri.reston.va.us> Message-ID: Ok, I'll play with that sometime tonight..I have to split now for a few hours. (my TA hours coming up in a bit here) The system is a Red Hat 5.1 system. ------------------------------------------------------------------------------- Corbett J. Klempay Quote of the Week: http://www2.acm.jhu.edu/~cklempay "Talent develops in quiet places, character in the full current of human life." PGP Fingerprint: 7DA2 DB6E 7F5E 8973 A8E7 347B 2429 7728 76C2 BEA1 ------------------------------------------------------------------------------- From cklempay@acm.jhu.edu Fri Jul 31 02:00:09 1998 From: cklempay@acm.jhu.edu (Corbett J. Klempay) Date: Thu, 30 Jul 1998 21:00:09 -0400 (EDT) Subject: [Mailman-Developers] /tmp/mailman.log Message-ID: Barry and the crew: I just put in the new driver a bit ago...and went to www2.acm.jhu.edu/mailman/listinfo /tmp/mailman.log showed up then...this is what it contained: [cklempay@chimera /tmp]$ cat mailman.log ===== import sys run_main() import os sys.path.insert() import StampedLogger import MultiLogger instantiating logger instantiating multi should now get normal error reporting [cklempay@chimera /tmp]$ Corbett From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Fri Jul 31 15:32:11 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 31 Jul 1998 10:32:11 -0400 (EDT) Subject: [Mailman-Developers] /tmp/mailman.log References: Message-ID: <13761.54635.212557.853073@anthem.cnri.reston.va.us> Something truly strange is happening. I don't understand how you can get that far through the driver script and still get a low level error with no traceback. Let me think about it -- I must be missing something. -Barry From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Fri Jul 31 16:25:55 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 31 Jul 1998 11:25:55 -0400 (EDT) Subject: [Mailman-Developers] Potential gotcha Message-ID: <13761.57859.883789.48657@anthem.cnri.reston.va.us> Corbett has been very kind in allowing me access to his machine to debug his problems. Since others have reported similar problems, I want to give you a heads up. Please double check that the programs in /home/mailman/cgi-bin are group owned by `mailman' and have the group sticky bit set. This is imperative; Mailman just won't work without this. I know need to figure out why the install procedure is broken on some systems, and how the driver script can better report and recover from these problems. Thanks Corbett! -Barry From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Fri Jul 31 16:56:35 1998 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 31 Jul 1998 11:56:35 -0400 (EDT) Subject: [Mailman-Developers] Potential gotcha References: <13761.57859.883789.48657@anthem.cnri.reston.va.us> Message-ID: <13761.59699.389393.16655@anthem.cnri.reston.va.us> Me> I know need to figure out why the install procedure is broken Me> on some systems, and how the driver script can better report Me> and recover from these problems. There is a bug in the top-level Makefile.in file which could cause the cgi-bin and mail subdirectories to not have their group sticky bit set. This in turn would cause the CGI binaries to be installed with the wrong group ownership. Please apply the following patch and do a fresh re-install, or make sure that CGI binaries and mail/wrapper are both group'd to mailman and have the g+s bit set (might as well set the bit on the cgi-bin and mail directories too). Sorry about that. -Barry -------------------- snip snip -------------------- Index: Makefile.in =================================================================== RCS file: /projects/cvsroot/mailman/Makefile.in,v retrieving revision 1.5 diff -c -r1.5 Makefile.in *** Makefile.in 1998/07/02 19:35:28 1.5 --- Makefile.in 1998/07/31 15:51:07 *************** *** 88,93 **** --- 88,94 ---- echo "Creating directory hierarchy $$dir"; \ ./mkinstalldirs $$dir; \ chmod $(DIRMODE) $$dir; \ + chmod g+s $$dir; \ else true; \ fi; \ done