From akuchlin@cnri.reston.va.us Tue Dec 1 16:03:49 1998 From: akuchlin@cnri.reston.va.us (Andrew M. Kuchling) Date: Tue, 1 Dec 1998 11:03:49 -0500 (EST) Subject: [Mailman-Developers] Hashing in private.py Message-ID: <13924.4628.294129.257598@amarok.cnri.reston.va.us> I just noticed that the token value used in private.py is just hash(list_name). A simple improvement is to change it to hash(SECRET + list_name) and then change the value of SECRET in private.py. An even better solution would be to do an MD5 hash of SECRET + list_name, but is it OK to assume that the md5 module is present?) (I haven't done a patch for md5 support; let me know if I should.) Also, since setting an archive to private doesn't seem to change the directory where it's archived, this means you have to configure the Web server accordingly. This should be documented somewhere; is it? -- A.M. Kuchling http://starship.skyport.net/crew/amk/ "All we know for sure is that we don't know anything for sure." "That is a particularly foolish thing to say, John Constantine. Light and darkness, life and death. These things are eternally certain." -- John Constantine and Dr Occult, in BOOKS OF MAGIC #1 *** private.py~ Mon Oct 19 16:14:54 1998 --- private.py Tue Dec 1 11:00:06 1998 *************** *** 98,102 **** c = Cookie.Cookie( os.environ['HTTP_COOKIE'] ) if c.has_key(list_name): ! if c[list_name].value == `hash(list_name)`: return 1 # No corresponding cookie. OK, then check for username, password --- 98,102 ---- c = Cookie.Cookie( os.environ['HTTP_COOKIE'] ) if c.has_key(list_name): ! if c[list_name].value == `hash(SECRET + list_name)`: return 1 # No corresponding cookie. OK, then check for username, password *************** *** 129,133 **** return 0 ! token = `hash(list_name)` c = Cookie.Cookie() c[list_name] = token --- 129,133 ---- return 0 ! token = `hash(SECRET + list_name)` c = Cookie.Cookie() c[list_name] = token From troy@akropolys.com Thu Dec 3 05:22:31 1998 From: troy@akropolys.com (Troy Morrison) Date: Wed, 2 Dec 1998 21:22:31 -0800 (PST) Subject: [Mailman-Developers] mailmain + sendmail = "clones" ??? Message-ID: Please forgive my lack of detailed understanding of Python and SendMail, but I'm wondering if anyone has run into this... I've just set up MailMan 1.0b6, and everything is working wonderfully, EXCEPT... after setting up the "test" list, I send a message to "test@host.com", I see the following in the mail logs: Dec 2 20:09:39 sendmail[26787]: UAA26787: from=, size=287, class=0, pri=30287, nrcpts=1, msgid=, proto=ESMTP, relay=troy@localhost Dec 2 20:09:39 enterprise sendmail[26788]: UAA26788: clone UAA26787, owner=test-admin Dec 2 20:09:45 enterprise sendmail[26788]: UAA26788: to="|/home/mailman/mail/wrapper post test", delay=00:00:06, xdelay=00:00:05, mailer=prog, stat=Sent And the message is never delivered to the subscribed parties. Is this something I can change in the sendmail configuration? Or should I punt sendmail in favor of smail/qmail/other MTA? Thanks, Troy From gstein@lyra.org Thu Dec 3 17:51:54 1998 From: gstein@lyra.org (Greg Stein) Date: Thu, 03 Dec 1998 09:51:54 -0800 Subject: [Mailman-Developers] [Fwd: Thread-SIG member |"nouser" bouncing - NOT disabled] Message-ID: <3666CFBA.73DD6888@lyra.org> This is a multi-part message in MIME format. --------------F7A1105FD490855F4A52B7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Note the erroneous "Content-Type:" in the first line of the message body. -g -- Greg Stein, http://www.lyra.org/ --------------F7A1105FD490855F4A52B7 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from ns1.lyra.org (root@ns1.lyra.org [208.192.43.10]) by svpal.svpal.org (8.9.0/8.9.0) with ESMTP id IAA06959 for ; Thu, 3 Dec 1998 08:16:49 -0800 (PST) From: mailman-owner@python.org Received: from python.org (parrot.python.org [132.151.1.90]) by ns1.lyra.org (8.8.5/8.8.5) with ESMTP id IAA00317 for ; Thu, 3 Dec 1998 08:16:12 -0800 Received: from python.org (localhost [127.0.0.1]) by python.org (8.9.1a/8.9.1) with ESMTP id LAA25438 for ; Thu, 3 Dec 1998 11:17:34 -0500 (EST) Received: from python.org (localhost [127.0.0.1]) by python.org (8.9.1a/8.9.1) with ESMTP id LAA25428 for ; Thu, 3 Dec 1998 11:17:29 -0500 (EST) Date: Thu, 3 Dec 1998 11:17:29 -0500 (EST) Message-Id: <199812031617.LAA25428@python.org> Subject: Thread-SIG member |"nouser" bouncing - NOT disabled To: thread-sig-admin@python.org Errors-To: mailman-owner@python.org MIME-version: 1.0 Content-type: multipart/mixed; boundary="132.151.1.90.1.25425.912701849.264.14506" List-Id: SIG on Process Threading in Python X-Mailman-Version: 1.0b7 This MIME message should be readable as plain text. --132.151.1.90.1.25425.912701849.264.14506 Content-type: text/plain; charset=us-ascii This is a Mailman mailing list bounce action notice: List: Thread-SIG Member: |"nouser" Action: Subscription not disabled. Reason: Excessive or fatal bounces. BUT: User not found. The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman-owner@python.org. --132.151.1.90.1.25425.912701849.264.14506 Content-type: text/plain; charset=us-ascii Received: from koro.off.connect.com.au (koro.off.connect.com.au [192.94.41.1]) by python.org (8.9.1a/8.9.1) with ESMTP id LAA25422 for ; Thu, 3 Dec 1998 11:17:25 -0500 (EST) Received: from localhost (localhost) by koro.off.connect.com.au with internal id DAA20027 (8.8.8/IDA-1.6); Fri, 4 Dec 1998 03:17:02 +1100 (EST) Date: Fri, 4 Dec 1998 03:17:02 +1100 (EST) From: Mail Delivery Subsystem Subject: Returned mail: User unknown Message-ID: <199812031617.DAA20027@koro.off.connect.com.au> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="DAA20027.912701822/koro.off.connect.com.au" Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --DAA20027.912701822/koro.off.connect.com.au The original message was received at Fri, 4 Dec 1998 03:17:00 +1100 (EST) from yarrina.connect.com.au [192.189.54.17] ----- The following addresses had permanent fatal errors ----- |"nouser" (expanded from: nouser) ----- Transcript of session follows ----- This username is no longer valid at connect.com.au. If you have a billing enquiry, please send mail to bills@connect.com.au. If you have a sales enquiry, please send mail to sales@connect.com.au. If you have a support enquiry, please send mail to support@connect.com.au. Alternatively, you can call +61 3 9251 3600. Thankyou. 550 |"nouser"... User unknown --DAA20027.912701822/koro.off.connect.com.au Content-Type: message/delivery-status Reporting-MTA: dns; koro.off.connect.com.au Received-From-MTA: dns; yarrina.connect.com.au Arrival-Date: Fri, 4 Dec 1998 03:17:00 +1100 (EST) Final-Recipient: rfc822; X-Actual-Recipient: rfc822; |nouser@koro.off.connect.com.au Action: failed Status: 5.1.1 Last-Attempt-Date: Fri, 4 Dec 1998 03:17:01 +1100 (EST) --DAA20027.912701822/koro.off.connect.com.au Content-Type: message/rfc822 Return-Path: Received: from yarrina.connect.com.au (yarrina.connect.com.au [192.189.54.17]) by koro.off.connect.com.au with ESMTP id DAA20025 (8.8.8/IDA-1.6); Fri, 4 Dec 1998 03:17:00 +1100 (EST) Received: from python.org (parrot.python.org [132.151.1.90]) by yarrina.connect.com.au with ESMTP id DAA25046 (8.8.8/IDA-1.7); Fri, 4 Dec 1998 03:16:58 +1100 (EST) Received: from python.org (localhost [127.0.0.1]) by python.org (8.9.1a/8.9.1) with ESMTP id LAA25400; Thu, 3 Dec 1998 11:16:33 -0500 (EST) Received: from orinoco.cisco.com (orinoco.cisco.com [171.71.125.34]) by python.org (8.9.1a/8.9.1) with ESMTP id LAA25379 for ; Thu, 3 Dec 1998 11:16:23 -0500 (EST) Received: from scothrel-pc (dhcp-sat-125-165.cisco.com [171.71.125.165]) by orinoco.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with SMTP id KAA06263; Thu, 3 Dec 1998 10:15:19 -0600 (CST) Message-ID: <000801be1ed7$e2d1ba30$a57d47ab@scothrel-pc.cisco.com> From: "Scott Cothrell" To: "Guido VanRossum" Cc: Subject: Re: [Thread-SIG] Re: Losing file output in C Python on NT Date: Thu, 3 Dec 1998 10:13:38 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: thread-sig-admin@python.org List-Id: SIG on Process Threading in Python Errors-To: thread-sig-admin@python.org X-BeenThere: thread-sig@python.org X-Mailman-Version: 1.0b7 >Thanks for posting. I bet this was the "unqualified 'except:' clause" >that I warned you about... Actually, it wasn't. The global except clause was intentional and was/is doing what we wanted. It was a mistyped variable name. > >I have little to comment on the rest of your post -- I'm not sure why >having too many threads would close your sockets, although when the >machine is too heavily loaded, anything can happen -- we've seen this >at CNRI with stress tests from Python as well. We are not at all sure whats going on with the sockets shutting down. The going bet is buffer overflow from too little service time. Its not a big deal since we can tune to it. > >--Guido van Rossum (home page: http://www.python.org/~guido/) > _______________________________________________ Thread-SIG maillist - Thread-SIG@python.org http://www.python.org/mailman/listinfo/thread-sig --DAA20027.912701822/koro.off.connect.com.au-- --132.151.1.90.1.25425.912701849.264.14506-- --------------F7A1105FD490855F4A52B7-- From klm@python.org Thu Dec 3 22:42:16 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 3 Dec 1998 17:42:16 -0500 (EST) Subject: [Mailman-Developers] The bulk issue Message-ID: Can anyone say why we are not putting "Precedence: bulk" on maillist traffic passed by mailman? I seem to recall raising the issue, and having objections, but i'm not recalling the objections, and my yearning to have vacation programs behave like we want (ignoring the messages) is still increasing. So i propose again that we inject our own precedence header iff one is not already there... Ken ---------- Forwarded message ---------- Date: Thu, 3 Dec 1998 14:34:08 -0800 (PST) From: via the vacation program Subject: away from my mail I will be out of the office until Monday December 14. Your email regarding "Re: [Mailman-Users] Compilation problems" will be read when I return. Larry Murdock From akuchlin@cnri.reston.va.us Fri Dec 4 18:22:25 1998 From: akuchlin@cnri.reston.va.us (Andrew M. Kuchling) Date: Fri, 4 Dec 1998 13:22:25 -0500 (EST) Subject: [Mailman-Developers] Patch to private.py Message-ID: <13928.10251.682491.452474@amarok.cnri.reston.va.us> Here's a patch to private.py which makes it 1) return text/plain as the content type if the file ends in .txt, and 2) look for .gz if doesn't exist, and uses the gzip module to read it. -- A.M. Kuchling http://starship.skyport.net/crew/amk/ How do you make sense of your life? Signal to noise: What's signal? What's noise? -- The dying film director in SIGNAL TO NOISE *** private.py 1998/12/04 16:26:29 1.1 --- private.py 1998/12/04 16:48:36 *************** *** 142,145 **** --- 142,149 ---- return path[1:] + def content_type(path): + if path[-3:] == '.gz': path = path[:-3] + if path[-4:] == '.txt': return 'text/plain' + return 'text/html' def main(): *************** *** 147,153 **** true_filename = os.path.join(ROOT, true_path(path) ) list_name = getListName(path) if os.path.isdir(true_filename): true_filename = true_filename + '/index.html' ! if not isAuthenticated(list_name): # Output the password form --- 151,164 ---- true_filename = os.path.join(ROOT, true_path(path) ) list_name = getListName(path) + + # If it's a directory, we have to append index.html in this script. + # We must also check for a gzipped file, because the text archives + # are usually stored in compressed form. if os.path.isdir(true_filename): true_filename = true_filename + '/index.html' ! if (not os.path.exists(true_filename) and ! os.path.exists(true_filename + '.gz') ): ! true_filename = true_filename + '.gz' ! if not isAuthenticated(list_name): # Output the password form *************** *** 167,180 **** print '\n\n', page % vars() sys.exit(0) ! print 'Content-type: text/html\n' ! ! print '\n\n' # Authorization confirmed... output the desired file try: ! f = open(true_filename, 'r') except IOError: print "

Archive File Not Found

" print "No file", path else: while (1): data = f.read(16384) --- 178,196 ---- print '\n\n', page % vars() sys.exit(0) ! # Authorization confirmed... output the desired file try: ! if true_filename[-3:] == '.gz': ! import gzip ! f = gzip.open(true_filename, 'r') ! else: ! f = open(true_filename, 'r') except IOError: + print 'Content-type: text/html\n' + print "

Archive File Not Found

" print "No file", path else: + print 'Content-type:', content_type(path), '\n' while (1): data = f.read(16384) From scott@chronis.pobox.com Fri Dec 4 21:32:53 1998 From: scott@chronis.pobox.com (Scott) Date: Fri, 4 Dec 1998 16:32:53 -0500 Subject: [Mailman-Developers] Hashing in private.py In-Reply-To: <13924.4628.294129.257598@amarok.cnri.reston.va.us>; from Andrew M. Kuchling on Tue, Dec 01, 1998 at 11:03:49AM -0500 References: <13924.4628.294129.257598@amarok.cnri.reston.va.us> Message-ID: <19981204163253.19593@chronis.icgroup.com> It is no more secure to have SECRET defined in the source code than to not have it at all. If anyone is going to spoof a cookie, then looking up the value of secret in the mailman distribution is trivial. While I'm not familiar with the benetits of md5 vs hash (it seems like both would be pretty much equally spoofable, and md5 just involves an extra import but i could be wrong), If we want to protect from cookie spoofing, then there should be a config variable for COOKIE_SECRET or the hash or md5 of the list_name concatenated to the admin site password might work. The point is to make SECRET variable. One potential drawback of md5 is that it can produce characters which need special escaping for http transactions. scott On Tue, Dec 01, 1998 at 11:03:49AM -0500, Andrew M. Kuchling wrote: | I just noticed that the token value used in private.py is just | hash(list_name). A simple improvement is to change it to hash(SECRET | + list_name) and then change the value of SECRET in private.py. An | even better solution would be to do an MD5 hash of SECRET + list_name, | but is it OK to assume that the md5 module is present?) | | (I haven't done a patch for md5 support; let me know if I should.) | | Also, since setting an archive to private doesn't seem to | change the directory where it's archived, this means you have to | configure the Web server accordingly. This should be documented | somewhere; is it? | | -- | A.M. Kuchling http://starship.skyport.net/crew/amk/ | "All we know for sure is that we don't know anything for sure." | "That is a particularly foolish thing to say, John Constantine. Light and | darkness, life and death. These things are eternally certain." | -- John Constantine and Dr Occult, in BOOKS OF MAGIC #1 | | | *** private.py~ Mon Oct 19 16:14:54 1998 | --- private.py Tue Dec 1 11:00:06 1998 | *************** | *** 98,102 **** | c = Cookie.Cookie( os.environ['HTTP_COOKIE'] ) | if c.has_key(list_name): | ! if c[list_name].value == `hash(list_name)`: | return 1 | # No corresponding cookie. OK, then check for username, password | --- 98,102 ---- | c = Cookie.Cookie( os.environ['HTTP_COOKIE'] ) | if c.has_key(list_name): | ! if c[list_name].value == `hash(SECRET + list_name)`: | return 1 | # No corresponding cookie. OK, then check for username, password | *************** | *** 129,133 **** | return 0 | | ! token = `hash(list_name)` | c = Cookie.Cookie() | c[list_name] = token | --- 129,133 ---- | return 0 | | ! token = `hash(SECRET + list_name)` | c = Cookie.Cookie() | c[list_name] = token | | | _______________________________________________ | Mailman-Developers maillist - Mailman-Developers@python.org | http://www.python.org/mailman/listinfo/mailman-developers | From gstein@lyra.org Mon Dec 7 10:10:50 1998 From: gstein@lyra.org (Greg Stein) Date: Mon, 07 Dec 1998 02:10:50 -0800 Subject: [Mailman-Developers] [Fwd: FW: mailman problem?] Message-ID: <366BA9AA.3E366FDB@lyra.org> This is a multi-part message in MIME format. --------------7E6DB674BD75CF9C10E1BE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailman should not present the "Digest: on/off" button when the list is not digestable. Possibly better error handling in general for this. For example, what happens when somebody tries to enable digest via email? Dunno how that would be handled... -g -- Greg Stein, http://www.lyra.org/ --------------7E6DB674BD75CF9C10E1BE Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from ns1.lyra.org (root@ns1.lyra.org [208.192.43.10]) by svpal.svpal.org (8.9.0/8.9.0) with ESMTP id VAA06071 for ; Sun, 6 Dec 1998 21:07:35 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ns1.lyra.org (8.8.5/8.8.5) with ESMTP id VAA00882 for ; Sun, 6 Dec 1998 21:08:39 -0800 Received: by mail2.microsoft.com with Internet Mail Service (5.5.2448.0) id ; Sun, 6 Dec 1998 21:08:47 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100DB90780@RED-MSG-50> From: Bill Tutt To: "'gstein@lyra.org'" Subject: FW: mailman problem? Date: Sun, 6 Dec 1998 21:08:47 -0800 Return-Receipt-To: Bill Tutt X-Mailer: Internet Mail Service (5.5.2448.0) FYI, looks like we hit a bug in mailman. The announce list is correctly configured to be non-digestable sine the traffic level will be very low. Mailman just needs a nice error page. Feel free to look into or forward to Ken, Barry, etc... I'll reply separately to Florent. Bill -----Original Message----- From: florent.heyworth@radbit.com [mailto:florent.heyworth@radbit.com] Sent: Sunday, December 06, 1998 3:45 PM To: Bill Tutt Subject: mailman problem? Hi I suscribed to the p2c-announce list and went on to the "Configuration for p2c-announce" after having sent and received confirmation for the list. I wanted to change the option "Set digest mode" to "on" at: http://mailman.pythonpros.com/mailman/options/p2c- announce/florent.heyworth@radbit.com I received the following error message: (see attachment) Cheers Florent Heyworth *** You better hope the cookie crumbles *** begin 600 ATT636586.txt M/'`^/&@S/E=E)W)E('-O6]U('=O=6QD(&QI:V4@=&\@:&5L<"!U2!T:&4@<')O M8FQE;2P@<&QE87-E#0IE;6%I;"!A(&-O<'D@;V8@=&AI2(L(&QI;F4@,3$R+"!I M;B!397157=O&)I=&UA<"P@:6UA9V4O:G!E9RP@*B\J(#PO=&0^ M/"]T; from Ken Manheimer on Thu, Dec 03, 1998 at 05:42:16PM -0500 References: Message-ID: <19981207034307.H2991@viega.org> I think you're *supposed* to use "Precedence: list" for a mailing list. Might want to check the RFC. On Thu, Dec 03, 1998 at 05:42:16PM -0500, Ken Manheimer wrote: > Can anyone say why we are not putting "Precedence: bulk" on maillist > traffic passed by mailman? I seem to recall raising the issue, and > having objections, but i'm not recalling the objections, and my yearning > to have vacation programs behave like we want (ignoring the messages) is > still increasing. So i propose again that we inject our own precedence > header iff one is not already there... > > Ken > > ---------- Forwarded message ---------- > Date: Thu, 3 Dec 1998 14:34:08 -0800 (PST) > From: via the vacation program > Subject: away from my mail > > I will be out of the office until Monday December 14. > Your email regarding > > "Re: [Mailman-Users] Compilation problems" > > will be read when I return. > > Larry Murdock > > > > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers From Brian@digicool.com Tue Dec 8 15:07:04 1998 From: Brian@digicool.com (Brian Lloyd) Date: Tue, 8 Dec 1998 10:07:04 -0500 Subject: [Mailman-Developers] 1.0b6 password cmd bug report Message-ID: <613145F79272D211914B0020AFF64019FC8E@gandalf.digicool.com> It seems that 1.0b6 doesnt correctly handle the password command via email: from MailCommandHandler.py: def ProcessPasswordCmd(self, args, cmd, mail): if len(args) <> 2: self.AddError("Usage: password ") return try: self.ChangeUserPassword(mail.GetSender(), args[0], args[1], args[1]) self.AddToResponse('Succeeded.') ProcessPasswordCmd is calling ChangeUserPassword with too many arguments, causing a TypeError: from SecurityManager.py: def ChangeUserPassword(self, user, newpw, confirm): self.IsListInitialized() Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com From akuchlin@cnri.reston.va.us Tue Dec 8 15:21:15 1998 From: akuchlin@cnri.reston.va.us (Andrew M. Kuchling) Date: Tue, 8 Dec 1998 10:21:15 -0500 (EST) Subject: [Mailman-Developers] Bug (?) report from Paul Everitt Message-ID: <13933.17329.597791.426465@amarok.cnri.reston.va.us> --UyqdjfJ7sY Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I don't know if anyone on this list is following the Zope mailing list, so just in case: Paul Everitt ran into the following problem. Can anyone offer a clue? -- A.M. Kuchling http://starship.skyport.net/crew/amk/ Good job, there, O'Grady. Always kick 'em when they're down. You might just make a detective yet. -- Lt. Burke, in SANDMAN MYSTERY THEATRE: "The Cannon", act IV --UyqdjfJ7sY Content-Type: message/rfc822 Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by newcnri.cnri.reston.va.us (8.9.1a/8.9.1) with SMTP id KAA26672; Tue, 8 Dec 1998 10:17:15 -0500 (EST) Received: from albert.digicool.com (albert.digicool.com [206.156.192.156]) by cnri.reston.va.us (8.9.1a/8.9.1) with ESMTP id KAA10543; Tue, 8 Dec 1998 10:17:03 -0500 (EST) Received: from albert.digicool.com (localhost [127.0.0.1]) by albert.digicool.com (8.9.1/8.9.1) with ESMTP id KAA11798; Tue, 8 Dec 1998 10:16:19 -0500 Received: from gandalf.digicool.com (gandalf.digicool.com [206.156.192.144]) by albert.digicool.com (8.9.1/8.9.1) with ESMTP id KAA11773 for ; Tue, 8 Dec 1998 10:16:02 -0500 Received: by gandalf.digicool.com with Internet Mail Service (5.5.1960.3) id ; Tue, 8 Dec 1998 10:19:33 -0500 Message-ID: <613145F79272D211914B0020AFF640192E24@gandalf.digicool.com> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) List-Id: Zope -- The Z Object Publishing Environment Errors-To: zope-admin@zope.org X-BeenThere: zope@zope.org X-Mailman-Version: 1.0b6 Content-Type: text/plain Content-Length: 1894 From: Paul Everitt Sender: zope-admin@zope.org To: "Dinu C. Gherman" , Joachim Schmitz Cc: zope@zope.org Subject: RE: [Zope] - Re: trying to subscribe Date: Tue, 8 Dec 1998 10:19:31 -0500 Dinu wrote: > Joachim wrote: > >I tried it in the subject-line, in the body, in body and > > subjectline no > >response. > > > It worked for me, but - another problem - I can't set > the digest option, at least not by sending an email to > zope-request@... (haven't tried yet over HTTP), although > MailMan said my new settings were fine. > > Maybe MailMan is not yet fully operational? I get the Mailman admin messages and I've been getting a number of complaints from it. Perhaps someone here can help me with Mailman? (I _really_ need to subscribe to the Mailman list!) --------------------------------------------- **** Subject line ignored: Returned mail: Host unknown (Name server: paradise.mgs.net: host not found) >>>> This is a MIME-encapsulated message **** this: Command UNKNOWN. >>>> --XAA09335.913093181/albert.digicool.com **** --xaa09335.913093181/albert.digicool.com: Command UNKNOWN. >>>> The original message was received at Mon, 7 Dec 1998 23:59:41 -0500 **** the: Command UNKNOWN. >>>> from localhost [127.0.0.1] **** from: Command UNKNOWN. >>>> ----- The following addresses had permanent fatal errors ----- **** -----: Command UNKNOWN. --------------------------------------------------------- Here's the one for digests: Traceback (innermost last): File "/home/mailman/cron/senddigests", line 37, in ? main() File "/home/mailman/cron/senddigests", line 34, in main list.SendDigestIfAny() File "/home/mailman/Mailman/Digester.py", line 194, in SendDigestIfAny self.SendDigestOnSize(0) File "/home/mailman/Mailman/Digester.py", line 206, in SendDigestOnSize self.SendDigest() File "/home/mailman/Mailman/Digester.py", line 288, in SendDigest self.DeliverToList(d.Present(mime=0), File "/home/mailman/Mailman/Deliverer.py", line 133, in DeliverToList status = cmdproc.close() IOError: (10, 'No child processes') --Paul --UyqdjfJ7sY-- From klm@python.org Wed Dec 9 17:05:51 1998 From: klm@python.org (Ken Manheimer) Date: Wed, 9 Dec 1998 12:05:51 -0500 (EST) Subject: [Mailman-Developers] 1.0b6 password cmd bug report In-Reply-To: <613145F79272D211914B0020AFF64019FC8E@gandalf.digicool.com> Message-ID: On Tue, 8 Dec 1998, Brian Lloyd wrote: > It seems that 1.0b6 doesnt correctly handle the > password command via email: > > from MailCommandHandler.py: > > def ProcessPasswordCmd(self, args, cmd, mail): > if len(args) <> 2: > self.AddError("Usage: password ") > return > try: > self.ChangeUserPassword(mail.GetSender(), > args[0], args[1], args[1]) > self.AddToResponse('Succeeded.') > > > ProcessPasswordCmd is calling ChangeUserPassword with > too many arguments, causing a TypeError: > > from SecurityManager.py: > > def ChangeUserPassword(self, user, newpw, confirm): > self.IsListInitialized() Thanks for pinpointing the trouble location! I've checked in a fix - in case you're interested, the problem was that ChangeUserPassword() was being invoked as if it validated the old password and then took the new password and it's verification copy, when in fact a separate function must be used to do the old password validation. I checked in the new version of the file to the cvs tree (and fixed a problem with the CVS update mechanism, so that the public tree is now up to date - it somehow got broken, and was out of sync for a few days). In case you just want the relevant lines of code, substitute the following lines for "try:" line in the code you cited in MailCommandHandler.py: sender = mail.GetSender() try: self.ConfirmUserPassword(sender, args[0]) (Using this instead of updating from the repository will lead to some redundant calls to mail.GetSender(), but that has negligible effect.) Ken From klm@python.org Fri Dec 11 00:10:29 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 10 Dec 1998 19:10:29 -0500 (EST) Subject: [Mailman-Developers] Exactly 100 subscribers on mailman-users@python.org Message-ID: <13936.25138.715614.637686@glyph.cnri.reston.va.us> I just happened to notice that there are exactly 100 subscribers to mailman-users. Besides admiring the nice, round number, it also occurred to me that it may be interesting to see how the number changes after john gives the presentation tomorrow at Usenix... Ken From gstein@lyra.org Thu Dec 17 00:15:28 1998 From: gstein@lyra.org (Greg Stein) Date: Wed, 16 Dec 1998 16:15:28 -0800 Subject: [Mailman-Developers] patch to subscribeack.txt Message-ID: <36784D20.56B10AC@lyra.org> I received a report that the welcome message is slightly misleading. I changed a couple lines in the middle to read: with the word "help" in the subject or body (don't add the quotes), and you will get back a message with instructions. Cheers, -g -- Greg Stein, http://www.lyra.org/ From klm@python.org Thu Dec 17 00:16:25 1998 From: klm@python.org (Ken Manheimer) Date: Wed, 16 Dec 1998 19:16:25 -0500 (EST) Subject: [Mailman-Developers] patch to subscribeack.txt In-Reply-To: <36784D20.56B10AC@lyra.org> Message-ID: On Wed, 16 Dec 1998, Greg Stein wrote: > I received a report that the welcome message is slightly misleading. I > changed a couple lines in the middle to read: > > with the word "help" in the subject or body (don't add the quotes), > and you will get back a message with instructions. Thanks - i happened to be editing another template, and it'll be a while until i could check in the changes, so i satisfied my checkin urges (hopefully enough to satisfy my "finish something today" compulsion to let me go home and get dinner:-) and applied your change. Um, don't expect this kind of turnaround in the future.-) :-) ken From gstein@lyra.org Thu Dec 17 23:31:14 1998 From: gstein@lyra.org (Greg Stein) Date: Thu, 17 Dec 1998 15:31:14 -0800 Subject: [Mailman-Developers] Deliverer.py Message-ID: <36799442.38D5A4C4@lyra.org> Two items that I noticed in Deliverer.py: 1) it writes to stderr, rather than logging 2) the writes do not have a final newline Cheers, -g -- Greg Stein, http://www.lyra.org/ From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Dec 18 05:14:47 1998 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 18 Dec 1998 00:14:47 -0500 (EST) Subject: [Mailman-Developers] Deliverer.py References: <36799442.38D5A4C4@lyra.org> Message-ID: <13945.58567.449227.63965@anthem.cnri.reston.va.us> >>>>> "GS" == Greg Stein writes: GS> Two items that I noticed in Deliverer.py: | 1) it writes to stderr, rather than logging | 2) the writes do not have a final newline Thanks Greg. Both of these are easily fixed by calling self.LogMsg() instead of sys.stderr.write(). -Barry From grin@tolna.net Fri Dec 18 10:41:32 1998 From: grin@tolna.net (Peter Gervai) Date: Fri, 18 Dec 1998 11:41:32 +0100 Subject: [Mailman-Developers] debug logging, long CC (Deliverer.py) In-Reply-To: <36799442.38D5A4C4@lyra.org>; from Greg Stein on Thu, Dec 17, 1998 at 03:31:14PM -0800 References: <36799442.38D5A4C4@lyra.org> Message-ID: <19981218114132.C12496@mail.tolna.net> On Thu, Dec 17, 1998 at 03:31:14PM -0800, Greg Stein wrote: > Two items that I noticed in Deliverer.py: > > 1) it writes to stderr, rather than logging This reminds me to the feeling when I first met mailman, when I thought: uhh, this program cannot log anything. I don't see what happens. There is some logfiles, but apart from the error log (which doesn't help always so well :)) there is no useful logfile. Is there a log for all processed messages for example? Especially the subscribe and confirmation messages? The bounces mailman processes, and other non-fatal errors? Maybe there is a possibility to have debug log but I didn't find it. It was especially sad when I put a larger list to mailman and found out that LOTS of mail did not get delivered, and there were NO sign anywhere in the logs that 1) delivery did not happen 2) why it did not happen. The other question is the reason why it didnt: it was because mailman wanted to send a mail with a very long CC list, and because security reasons the CC's were maxed at 15, so delivery failed with 5xx error somewhere in the middle and mail got silently lost. Is there any settings to set how many CC's mailman will use at most? At least it should later be documented somewhere that mailman requires such limitations lifted. best regards, grin From boldi@budapest.hu Fri Dec 18 22:11:23 1998 From: boldi@budapest.hu (Bencsath Boldizsar) Date: Fri, 18 Dec 1998 23:11:23 +0100 (CET) Subject: [Mailman-Developers] small sec problem / or feuture (?) Message-ID: Hi, I am not list member, but didn't find any bugreport address in the docs of mailman ( please make one.. :) ) So, in 1.0b6 there is a small problem: Pendig messages can be seen by anyone / i didn't checked the privacy options, but it's more logical, that pending messages are only viewable by the admin through the password. check http://www.anything.something/mailman/admindb/ boldi -------------------------------- Bencsath Boldizsar boldi@inf.bme.hu boldi@rulez.org greetings to mol S.A.I.C. VIP Protection SASSTIXS http://www.inf.bme.hu/~boldi -------------------------------- From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Dec 19 04:38:44 1998 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 18 Dec 1998 23:38:44 -0500 (EST) Subject: [Mailman-Developers] small sec problem / or feuture (?) References: Message-ID: <13947.11732.567166.584256@anthem.cnri.reston.va.us> >>>>> "BB" == Bencsath Boldizsar writes: BB> Hi, I am not list member, but didn't find any bugreport BB> address in the docs of mailman ( please make one.. :) ) mailman-developers@python.org is fine. I've added a note to the BUGS file. BB> So, in 1.0b6 there is a small problem: Pendig messages can be BB> seen by anyone / i didn't checked the privacy options, but BB> it's more logical, that pending messages are only viewable by BB> the admin through the password. check BB> http://www.anything.something/mailman/admindb/ boldi Good point. I think doing the admin authentication upfront is better for dealing with pending messages too. I've got this working and will check it in for the next release. Thanks, -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Dec 19 05:21:34 1998 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 19 Dec 1998 00:21:34 -0500 (EST) Subject: [Mailman-Developers] debug logging, long CC (Deliverer.py) References: <36799442.38D5A4C4@lyra.org> <19981218114132.C12496@mail.tolna.net> Message-ID: <13947.14302.507778.960606@anthem.cnri.reston.va.us> >>>>> "PG" == Peter Gervai writes: PG> This reminds me to the feeling when I first met mailman, when PG> I thought: uhh, this program cannot log anything. I don't see PG> what happens. There is some logfiles, but apart from the error PG> log (which doesn't help always so well :)) there is no useful PG> logfile. Is there a log for all processed messages for PG> example? Especially the subscribe and confirmation messages? PG> The bounces mailman processes, and other non-fatal errors? Lots of stuff should be getting logged, but I can't remember what's in 1.0b6 (Ken?). You should see every post getting logged, subscribes/unsubscribes, digests, and of course errors. The error logging ought to be very helpful if you're trying to track down a Mailman bug (but there are none any of *those* right?! :-). I'm sure there's more we could log though. PG> Maybe there is a possibility to have debug log but I didn't PG> find it. It was especially sad when I put a larger list to PG> mailman and found out that LOTS of mail did not get delivered, PG> and there were NO sign anywhere in the logs that 1) delivery PG> did not happen 2) why it did not happen. You don't say what version of Mailman you're using. There are a couple of places that bugs can happen to prevent message delivery. If it happens in the mail wrapper binary (e.g. you got your mail-gid wrong), you'll need to enable syslog to catch those, since they don't make it to Python yet. If the error happens within the Python part of Mailman, you should see those in the error log. Same with CGI. The error logs (for CGI) should be quite complete; they should contain the Python traceback pointing you right to the source line that crapped out, along with a dump of the environment variables the CGI script saw. PG> The other question is the reason why it didnt: it was because PG> mailman wanted to send a mail with a very long CC list, and PG> because security reasons the CC's were maxed at 15, so PG> delivery failed with 5xx error somewhere in the middle and PG> mail got silently lost. Is there any settings to set how many PG> CC's mailman will use at most? At least it should later be PG> documented somewhere that mailman requires such limitations PG> lifted. Look in the Privacy Options. There's an option that says "Ceiling on acceptable number of recipients for a posting". This defaults to 10. BTW, if this is really why the messages are not being delivered, they probably aren't just lost. They get held for administrative approval for a period of time. Check the pending messages for the list. Hope that helps, -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Dec 19 06:13:08 1998 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 19 Dec 1998 01:13:08 -0500 (EST) Subject: [Mailman-Developers] The bulk issue References: <19981207034307.H2991@viega.org> Message-ID: <13947.17396.643301.995943@anthem.cnri.reston.va.us> >>>>> "JV" == John Viega writes: JV> I think you're *supposed* to use "Precedence: list" for a JV> mailing list. Might want to check the RFC. I'm not finding this in the docs I've consulted, RFC 2076 and its Jan-1998 update: http://www.dsv.su.se/~jpalme/ietf/ietf-mail-attributes.html Looks like Precedence: bulk is as close as it gets. Interesting enough, we don't add this to posted messages, but we *do* add this to emailed passwords. I'll try to add this, and (maybe) other list related headers referred to in the document. -Barry From klm@python.org Sat Dec 19 06:45:40 1998 From: klm@python.org (Ken Manheimer) Date: Sat, 19 Dec 1998 01:45:40 -0500 (EST) Subject: [Mailman-Developers] The bulk issue In-Reply-To: <13947.17396.643301.995943@anthem.cnri.reston.va.us> Message-ID: On Sat, 19 Dec 1998, Barry A. Warsaw wrote: > >>>>> "JV" == John Viega writes: > > JV> I think you're *supposed* to use "Precedence: list" for a > JV> mailing list. Might want to check the RFC. > > I'm not finding this in the docs I've consulted, RFC 2076 and its > Jan-1998 update: > > http://www.dsv.su.se/~jpalme/ietf/ietf-mail-attributes.html > > Looks like Precedence: bulk is as close as it gets. Interesting > enough, we don't add this to posted messages, but we *do* add this to > emailed passwords. I'll try to add this, and (maybe) other list > related headers referred to in the document. I actually did look it over a bit, and from RFC 822 (or somesuch) it sounds like precedence: bulk has a dubious pedegree. More importantly, after reviewing the vacation man page, i realized that the precedence: bulk header would be redundant for mailing list traffic, since most of the kinds of things that respect it also refrain from responding to messages that do not have the recipient's address explicitly mentioned among the destination addresses, which is inherently the case for maillist traffic - so the precedence: bulk is unnecessary. (I should have mentioned this when i originally realized this.) So i'm not sure adding precedence bulk is a good idea. The password reminders (and other administrative messages) are another matter, because they are directed to specific individuals. I actually added the precedence: bulk to the password reminders in a mad scramble just before the end of last month - the scramble was because i *dreaded* the deluge of vacation-message responses i was getting, as mailman-owner, from the python.org mailing list mass reminders delivery... Ken From roy@endeavor.med.nyu.edu Sat Dec 19 12:35:53 1998 From: roy@endeavor.med.nyu.edu (Roy Smith) Date: Sat, 19 Dec 1998 07:35:53 -0500 Subject: [Mailman-Developers] routing loop circuit breakers In-Reply-To: <13947.17396.643301.995943@anthem.cnri.reston.va.us> Message-ID: <136508.3123041753@mcsv29-p2.med.nyu.edu> We just had a mail routing loop disaster on one of our mailing lists (not run with mailmail). A list subscriber had a mis-behaved vacation responder which flooded the list with about 100 copies of a vacation message in the course of a couple of hours before it got noticed. You can imagine the mess this caused. Does mailman have any soft of circuit breaker to prevent something like this? If so, it would probably be the incentive we need to change from majordomo to mailman. I guess the right heuristic to have prevented this would be something like refusing mail from anybody if they have sent more than N messages in X minutes. I could even imagine a fast-blow and slow-blow threshold, i.e. "5 messages in 10 minutes or 20 messages in 24 hours" type of thing. Is this possible? Roy Smith New York University School of Medicine 550 First Avenue, New York, NY 10016 From Harald.Meland@usit.uio.no Sat Dec 19 15:00:36 1998 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 19 Dec 1998 16:00:36 +0100 Subject: [Mailman-Developers] The bulk issue In-Reply-To: Ken Manheimer's message of "Sat, 19 Dec 1998 01:45:40 -0500 (EST)" References: Message-ID: [Ken Manheimer] > More importantly, after reviewing the vacation man page, i realized > that the precedence: bulk header would be redundant for mailing list > traffic, since most of the kinds of things that respect it also > refrain from responding to messages that do not have the recipient's > address explicitly mentioned among the destination addresses, which > is inherently the case for maillist traffic - so the precedence: > bulk is unnecessary. I'd say inserting a "Precedence: list" header is a good thing anyway. Consider the case of a vacation program not knowing which addresses maps to which mail users -- such a vacation program (which is not at all uncommon) would have (very nearly) no idea whether the address in the To: header is a mailing list address or some strange alias pointing to the mail user it is trying to do it's thing for. Giving such a vacation program an additional header to base it's judgement on is IMHO a good thing. I have no idea where, or even if, "Precedence: list" is standardized in any way, but I think that thath is what majordomo is inserting. Being compatible with majordomo when it doesn't cost us anything is also, IMHO, a good thing. The only reason I see for _not_ adding any Precedence: header, is that Mailman-delivered messages have half a truckload of headers as it is. But that, IMHO, isn't really a strong argument -- as long as all the headers are there for some good reason, they _should_ be in there. Just my ¤.02, -- Harald From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Dec 19 20:35:49 1998 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 19 Dec 1998 15:35:49 -0500 (EST) Subject: [Mailman-Developers] The bulk issue References: <13947.17396.643301.995943@anthem.cnri.reston.va.us> Message-ID: <13948.3621.659652.961983@anthem.cnri.reston.va.us> >>>>> "KM" == Ken Manheimer writes: KM> So i'm not sure adding precedence bulk is a good idea. Already, I suppose we can forget it, even though it would be trivial to add. I think you've got the right trade-off. I do want to look at adding the other IETF draft mailinglist headers, and may look into that. -Barry From grin@tolna.net Sat Dec 19 20:36:07 1998 From: grin@tolna.net (Peter Gervai) Date: Sat, 19 Dec 1998 21:36:07 +0100 Subject: [Mailman-Developers] debug logging, long CC (Deliverer.py) In-Reply-To: <13947.14302.507778.960606@anthem.cnri.reston.va.us>; from Barry A. Warsaw on Sat, Dec 19, 1998 at 12:21:34AM -0500 References: <36799442.38D5A4C4@lyra.org> <19981218114132.C12496@mail.tolna.net> <13947.14302.507778.960606@anthem.cnri.reston.va.us> Message-ID: <19981219213607.B11937@mail.tolna.net> Barry, On Sat, Dec 19, 1998 at 12:21:34AM -0500, Barry A. Warsaw wrote: > > >>>>> "PG" == Peter Gervai writes: > > PG> This reminds me to the feeling when I first met mailman, when > PG> I thought: uhh, this program cannot log anything. I don't see > PG> what happens. There is some logfiles, but apart from the error > PG> log (which doesn't help always so well :)) there is no useful > PG> logfile. Is there a log for all processed messages for > PG> example? Especially the subscribe and confirmation messages? > PG> The bounces mailman processes, and other non-fatal errors? > > Lots of stuff should be getting logged, but I can't remember what's in > 1.0b6 (Ken?). You should see every post getting logged, > subscribes/unsubscribes, digests, and of course errors. No, definitely I completely miss the logfile showing the posts. Subscribes/unsubs get logged as well as errors, though error log a bit hard to use because it doesn't show the variables failed. > The error > logging ought to be very helpful if you're trying to track down a > Mailman bug (but there are none any of *those* right?! :-). Hehe, don't tell me, I'm that guy with the exim and the questions about permissions nobody was able to answer, as well as error messages being unfamiliar to anyone. :-) > PG> Maybe there is a possibility to have debug log but I didn't > PG> find it. It was especially sad when I put a larger list to > PG> mailman and found out that LOTS of mail did not get delivered, > PG> and there were NO sign anywhere in the logs that 1) delivery > PG> did not happen 2) why it did not happen. > > You don't say what version of Mailman you're using. There are a Sorry, trying to be at the lastest released, this time 1.0b6. I realized that I had a new logfile, namely smtp-failures. :-) It shows at least the error message caused the delivery to fail. Nice. > PG> The other question is the reason why it didnt: it was because > PG> mailman wanted to send a mail with a very long CC list, and > PG> because security reasons the CC's were maxed at 15, so > PG> delivery failed with 5xx error somewhere in the middle and > PG> mail got silently lost. Is there any settings to set how many > PG> CC's mailman will use at most? At least it should later be > PG> documented somewhere that mailman requires such limitations > PG> lifted. > > Look in the Privacy Options. There's an option that says "Ceiling on > acceptable number of recipients for a posting". This defaults to 10. It's been 10 by default. Doesn't seem to matter at all. > BTW, if this is really why the messages are not being delivered, they > probably aren't just lost. They get held for administrative approval > for a period of time. Check the pending messages for the list. Of course I regularly check the waiting messages as I'm the owner as well but there were none waiting, obviosuly. The message got delivered to the small batch (outside users, 3 cc) and lost for the big one (local users, 20-50 cc)... thank you, grin From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Dec 19 20:42:15 1998 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 19 Dec 1998 15:42:15 -0500 (EST) Subject: [Mailman-Developers] The bulk issue References: Message-ID: <13948.4007.271847.853690@anthem.cnri.reston.va.us> >>>>> "HM" == Harald Meland writes: HM> I have no idea where, or even if, "Precedence: list" is HM> standardized in any way, but I think that thath is what HM> majordomo is inserting. Being compatible with majordomo when HM> it doesn't cost us anything is also, IMHO, a good thing. As far as I can tell, it is not documented anywhere; not even in the update to RFC 2076. I'll see if I can search around in Majordomo to see what they do, but if anybody else can verify this, it would be helpful. HM> The only reason I see for _not_ adding any Precedence: header, HM> is that Mailman-delivered messages have half a truckload of HM> headers as it is. But that, IMHO, isn't really a strong HM> argument -- as long as all the headers are there for some good HM> reason, they _should_ be in there. Yeah, and the IETF draft adds 9 more headers ;-( -Barry From klm@python.org Sat Dec 19 21:33:44 1998 From: klm@python.org (Ken Manheimer) Date: Sat, 19 Dec 1998 16:33:44 -0500 (EST) Subject: [Mailman-Developers] debug logging, long CC (Deliverer.py) In-Reply-To: <19981219213607.B11937@mail.tolna.net> Message-ID: On Sat, 19 Dec 1998, Peter Gervai wrote: > Barry, > > On Sat, Dec 19, 1998 at 12:21:34AM -0500, Barry A. Warsaw wrote: > > > > >>>>> "PG" == Peter Gervai writes: > > > > PG> This reminds me to the feeling when I first met mailman, when > > PG> I thought: uhh, this program cannot log anything. I don't see > > PG> what happens. There is some logfiles, but apart from the error > > PG> log (which doesn't help always so well :)) there is no useful > > PG> logfile. Is there a log for all processed messages for > > PG> example? Especially the subscribe and confirmation messages? > > PG> The bounces mailman processes, and other non-fatal errors? > > > > Lots of stuff should be getting logged, but I can't remember what's in > > 1.0b6 (Ken?). You should see every post getting logged, > > subscribes/unsubscribes, digests, and of course errors. > > No, definitely I completely miss the logfile showing the posts. > Subscribes/unsubs get logged as well as errors, though error log > a bit hard to use because it doesn't show the variables failed. Logging of posts is in the "frontier" (CVS repository) version, soon to be released as 1.0b7. (It was added by scott cotton, not too long after 1.0b6 was released.) I should add that i was surprised to see you say "this program cannot log anything". We don't pretend Mailman is perfect, but it's discouraging to hear such low judgements ("no useful logfile"), particularly about things we're working on improving (and about which you seem to be mistaken - we've had logs for both subscribe and bounce activity for a while!) I agree that it would be nice to be able to glean more about the specific coding errors from the error log - but we're mostly dealing with the limits of the resolution of Python tracebacks, here. This actually is something that is improving in Python (due to some recent work by barry!), and in general i expect the situation to progressively improve. (I've added to the todo list that error messages should say more about failed file, maillist, etc identities.) > > PG> The other question is the reason why it didnt: it was because > > PG> mailman wanted to send a mail with a very long CC list, and > > PG> because security reasons the CC's were maxed at 15, so > > PG> delivery failed with 5xx error somewhere in the middle and > > PG> mail got silently lost. Is there any settings to set how many > > PG> CC's mailman will use at most? At least it should later be > > PG> documented somewhere that mailman requires such limitations > > PG> lifted. > > > > Look in the Privacy Options. There's an option that says "Ceiling on > > acceptable number of recipients for a posting". This defaults to 10. > > It's been 10 by default. Doesn't seem to matter at all. There is a serious architectural obstacle for delivery failures that occur for destinations on the local system - because the MTA doesn't generate any bounce messages in that case. This is something that should be corrected in our smtplib (i'm not sure whether the interface in the standard python smtplib addresses the problem, either), but at least the smtp-failures log file should register the problem. That said, once again the frontier version has a fix for your particular problem (once again, from scott cotton). It's in the form of a new parameter, SMTP_MAX_RCPTS, which constrains the size of the groups into which destinations are batched for delivery. You should be able to set that to 10, or whatever, and prevent your MTA from getting passed batches larger than 10. This will probably reduce the speed of the delivery process, but that sounds like a tradeoff that your site has elected for, in general. > > BTW, if this is really why the messages are not being delivered, they > > probably aren't just lost. They get held for administrative approval > > for a period of time. Check the pending messages for the list. > > Of course I regularly check the waiting messages as I'm the owner as well > but there were none waiting, obviosuly. The message got delivered to the > small batch (outside users, 3 cc) and lost for the big one (local > users, 20-50 cc)... I'm really suspecting you're not talking about addresses in the CC headers, but rather groups into which deliveries for the list were batched. Sorry if i'm mistaken - if i am, we'll need more info to determine why the size-of-cc-option is failing for you... Ken Manheimer klm@python.org 703 620-8990 x268 (orporation for National Research |nitiatives # If you appreciate Python, consider joining the PSA! # # . # From grin@tolna.net Sat Dec 19 22:49:55 1998 From: grin@tolna.net (Peter Gervai) Date: Sat, 19 Dec 1998 23:49:55 +0100 Subject: [Mailman-Developers] debug logging, long CC (Deliverer.py) In-Reply-To: ; from Ken Manheimer on Sat, Dec 19, 1998 at 04:33:44PM -0500 References: <19981219213607.B11937@mail.tolna.net> Message-ID: <19981219234955.E11937@mail.tolna.net> Ken, > > > PG> This reminds me to the feeling when I first met mailman, when > > > PG> I thought: uhh, this program cannot log anything. I don't see [...] > I should add that i was surprised to see you say "this program cannot > log anything". We don't pretend Mailman is perfect, but it's > discouraging to hear such low judgements ("no useful logfile"), Oh, sorry if I sounded like that, it wasn't intentional! I wanted to tell about when I was young and ingorant to the great aspects of mailman, and when I first saw it (and the next 397 times when I tried to get it started in my brainwashed environment) I felt the miss of the detailed logfiles about what happens. But of course since I managed it to work fine I don't feel the miss. I just think others might need them in the startup phase, at least until the program gets rid of that 'b' from the version number. :-) I think I state the obvious when mentioning that even I avoid Python I've fallen in love with mailman as it not only manages lists, but do it with a royal superiority. :) The UI is very useful, pretty; the bounce detection is wise, and the admin UI is easy to use. Bugreports and (uncalled) complaints always sound a bit disappointing, maybe I'll try to put some "you know that we love mailman and that's why we make such bugreports" :) to make you feel it's not because I think it's BAD but because I want it to be BETTER. Better than best, you see. :) > particularly about things we're working on improving (and about which > you seem to be mistaken - we've had logs for both subscribe and bounce > activity for a while!) Apologies for not mentioning those logs, but at least I never mentioned they doesn't exist. :) > I agree that it would be nice to be able to glean more about the > specific coding errors from the error log - but we're mostly dealing > with the limits of the resolution of Python tracebacks, here. This I don't know Python that deep enough, I just suspected that being an interpreted language it could evaluate the line in question so find variables in the line in question and tell their values... Maybe this only shows my lack of Pythonness. :) > > > PG> The other question is the reason why it didnt: it was because > > > PG> mailman wanted to send a mail with a very long CC list, and [...] > > > Look in the Privacy Options. There's an option that says "Ceiling on > > > acceptable number of recipients for a posting". This defaults to 10. > > > > It's been 10 by default. Doesn't seem to matter at all. > > There is a serious architectural obstacle for delivery failures that > occur for destinations on the local system - because the MTA doesn't > generate any bounce messages in that case. This is something that > should be corrected in our smtplib (i'm not sure whether the interface > in the standard python smtplib addresses the problem, either), but at > least the smtp-failures log file should register the problem. Unfortunately that was quite hard to spot... If I weren't in the batch disappearing I'd never see there was a problem at all. > > Of course I regularly check the waiting messages as I'm the owner as well > > but there were none waiting, obviosuly. The message got delivered to the > > small batch (outside users, 3 cc) and lost for the big one (local > > users, 20-50 cc)... > > I'm really suspecting you're not talking about addresses in the CC > headers, but rather groups into which deliveries for the list were > batched. Sorry if i'm mistaken - if i am, we'll need more info to > determine why the size-of-cc-option is failing for you... I can't really tell you whether it's CC or multiple RCPT TO: fields since I don't have the logfile :-)) But I'm confident that the error was caused by having a limit on the number of recipients a single mail can contain, no matter the method. (Posted mail did not contain any cc at all, if that was your question.) To mailman limited numbers of CC could mean a tradeoff (more batches) but efficiently stops ignorant users from creating mass-mailings. In these times we live in this do matter. bye, grin From Harald.Meland@usit.uio.no Sun Dec 20 13:25:27 1998 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 20 Dec 1998 14:25:27 +0100 Subject: [Mailman-Developers] The bulk issue In-Reply-To: "Barry A. Warsaw"'s message of "Sat, 19 Dec 1998 15:42:15 -0500 (EST)" References: <13948.4007.271847.853690@anthem.cnri.reston.va.us> Message-ID: [Barry A. Warsaw] > >>>>> "HM" == Harald Meland writes: > > HM> I have no idea where, or even if, "Precedence: list" is > HM> standardized in any way, but I think that thath is what > HM> majordomo is inserting. Being compatible with majordomo when > HM> it doesn't cost us anything is also, IMHO, a good thing. > > As far as I can tell, it is not documented anywhere; not even in the > update to RFC 2076. Sorry, my mistake. I should have said "Due to the behaviour I am seeing on some of the majordomo lists I am on, I think that majordomo inserts `Precedence: list' headers." Now that I have actually done some grepping of the majordomo source, I can't find anything in majordomo 1.94.4 which should cause the precedence header to default to anything but "bulk". Thus, I agree that inserting "Precedence: list" as a default seems inappropriate. However, I believe that not inserting any Precedence: header *at*all* will cause trouble. My example (the vacation program which doesn't know the mapping between local users and local addresses) was meant to show that inserting *a* Precedence: header would be useful. > I'll see if I can search around in Majordomo to see what they do, > but if anybody else can verify this, it would be helpful. I don't know majordomo very intimately (neither do I want to get to know it all that much better :), so getting a second opinion would be wise :) Still, config_parse.pl says: # provide list of known keys. If value is '', then the key is undefined # I.e. the action is just as though there was no keyword found. # otherwise the value is the default value for the keyword. # if the value starts with #!, the rest of the value is eval'ed %known_keys = ( [...] 'precedence', 'bulk', # Set/install precendence header implying that "bulk" is the default value for the "precedence" configuration setting. -- Harald From neves@inf.puc-rio.br Mon Dec 21 23:27:08 1998 From: neves@inf.puc-rio.br (Paulo Eduardo Neves) Date: Mon, 21 Dec 1998 20:27:08 -0300 Subject: [Mailman-Developers] The bulk issue References: <13948.4007.271847.853690@anthem.cnri.reston.va.us> Message-ID: <367ED94C.C66FFD69@inf.puc-rio.br> "Barry A. Warsaw" wrote: > > >>>>> "HM" == Harald Meland writes: > > HM> I have no idea where, or even if, "Precedence: list" is > HM> standardized in any way, but I think that thath is what > HM> majordomo is inserting. Being compatible with majordomo when > HM> it doesn't cost us anything is also, IMHO, a good thing. > > As far as I can tell, it is not documented anywhere; not even in the > update to RFC 2076. I'll see if I can search around in Majordomo to > see what they do, but if anybody else can verify this, it would be > helpful. I've signed Listserv support list for sometime and this was a frequent question. The Precedence: list header isn't in any standard. If I remember well you will find info just in sendmail docs. It was invented by Eric Allman, who is the author of Sendmail mail and of the vacation program. Listserv refuses to add it since it isn't in the standards. > > HM> The only reason I see for _not_ adding any Precedence: header, > HM> is that Mailman-delivered messages have half a truckload of > HM> headers as it is. But that, IMHO, isn't really a strong > HM> argument -- as long as all the headers are there for some good > HM> reason, they _should_ be in there. > > Yeah, and the IETF draft adds 9 more headers ;-( I agree that there's no problem adding it, since it avoids problems to the list. []s -- Paulo Eduardo Neves PUC-Rio de Janeiro Pager: Central: 292-4499 cod. 213 99 64 ou use a URL: http://www.learn.fplf.org.br/neves/mensagempager.html From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Dec 22 04:18:20 1998 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 21 Dec 1998 23:18:20 -0500 (EST) Subject: [Mailman-Developers] smtplib.py Message-ID: <13951.7564.907978.393759@anthem.cnri.reston.va.us> I think I've integrated the Python 1.5.2 smtplib.py into Mailman for 1.0b7. I'm no smtp expert so I'd like someone with CVS access to double check what I've done. Here's a summary. I am removing Mailman/smtplib.py, and creating a new package directory inside Mailman called Mailman/pythonlib. This package will contain newer versions of standard Python libraries, that may not exist (or be out of date) out in the field. E.g. this directory now contains smtplib.py from nearly-Python-1.5.2. If we ever have version skew down the road, this may contain other copies of such libraries. When require Python 1.5.2 or better, we can remove Mailman/pythonlib/smtplib.py Now, I've tracked down every reference to smtplib.py and the only useful one seems to be Mailman/Utils.py. I've removed all other imports of smtplib from places where they were not used. Then I modified TrySMTPDelivery() in Utils.py to get the correct smtplib (standard Python one if the attribute smptlib.SMTP.ehlo exists, otherwise, it imports the one out of the Mailman.pythonlib package). Finally, I rewrote the code in this function to call the standard interface, which seems very simple: essentially call smtplib.SMTP(...).sendmail(). In my limited testing, this appears to work just fine. I plan to check all this stuff in in a few moments. Please someone double check me. If I've messed up badly, I'll revert. Also, I plan to move bin/update_to_10b6 to bin/update. We'll just keep adding new update procedures to this script as new versions are released. I plan to add removal of $prefix/Mailman/smtplib.py{,c}. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Dec 23 00:12:47 1998 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 22 Dec 1998 19:12:47 -0500 (EST) Subject: [Mailman-Developers] The bulk issue References: <13948.4007.271847.853690@anthem.cnri.reston.va.us> <367ED94C.C66FFD69@inf.puc-rio.br> Message-ID: <13952.13695.962925.907350@anthem.cnri.reston.va.us> Okay, I have added "Precedence: bulk" headers to both normal deliveries and to the digest envelopes. While there's some disagreement among people, this definitely helps some folks, and shouldn't hurt everyone else. I am not adding other non-standard mailing list related headers, since that's *a lot* more headers for IETF draft support of a feature with marginal value. We could add these later easily. -Barry From sjp@buzzsaw.net Wed Dec 23 22:02:33 1998 From: sjp@buzzsaw.net (Steve Phillips) Date: Wed, 23 Dec 1998 16:02:33 -0600 (EST) Subject: [Mailman-Developers] Problems getting news/mail gateway working (with fixes) Message-ID: System: Debian: 2.0 Mailman: 1.0b6 (compiled, not from .deb package) Inn: 1.7.2 (debian package version 1.7.2-4) I found one bug in the Python source and one installation error: I'm trying to set up Mailman on my system to gateway between mail and news. I found I was getting the following error in my syslog when trying to gateway mail to news: ----------------------------------------------------------------------- Dec 23 13:05:00 hodag /USR/SBIN/CRON[12324]: (mailman) CMD (/usr/bin/python /hom e/m/mailman/cron/gate_news) Dec 23 13:09:05 hodag sendmail[12352]: NAA12352: from=, si ze=671, class=0, pri=30671, nrcpts=1, msgid=<36813FAF.710DD6C6@siliconlogic.com> , proto=ESMTP, relay=relay.siliconlogic.com [207.67.84.2] Dec 23 13:09:05 hodag sendmail[12353]: NAA12353: clone NAA12352, owner=test-admi n Dec 23 13:09:07 hodag nnrpd[12358]: hodag.buzzsaw.net connect Dec 23 13:09:07 hodag nnrpd[12358]: hodag.buzzsaw.net post failed Duplicate "Sen der" header Dec 23 13:09:07 hodag nnrpd[12358]: hodag.buzzsaw.net exit articles 0 groups 0 Dec 23 13:09:07 hodag nnrpd[12358]: hodag.buzzsaw.net posts received 0 rejected 1 Dec 23 13:09:07 hodag nnrpd[12358]: hodag.buzzsaw.net times user 0.010 system 0. 010 elapsed 0.131 ----------------------------------------------------------------------- Looks like it failed because the header that innd got was bad. Investigation revealed this bit of code from GatewayManager.py: subj = msg.getheader('subject') if not subj: msg.SetHeader('Subject', '%s(no subject)' % prefix) if self.reply_goes_to_list: del msg['reply-to'] msg.headers.append('Reply-To: %s\n' % self.GetListEmail()) msg.headers.append('Sender: %s\n' % self.GetAdminEmail()) msg.headers.append('Errors-To: %s\n' % self.GetAdminEmail()) msg.headers.append('X-BeenThere: %s\n' % self.GetListEmail()) msg.headers.append('Newsgroups: %s\n' % self.linked_newsgroup) Looks like a new Sender: line is getting added, but the original one is not removed. I commented out this line and then things started working. As for news to mail: I got the following error for that: ----------------------------------------------------------------------- Received: (from root@localhost) by hodag.buzzsaw.net (8.8.8/8.8.8/Debian/GNU) id PAA13832 for mailman; Wed, 23 Dec 1998 15:30:05 -0600 Date: Wed, 23 Dec 1998 15:30:05 -0600 Message-Id: <199812232130.PAA13832@hodag.buzzsaw.net> From: root (Cron Daemon) To: mailman Subject: Cron /usr/bin/python /home/m/mailman/cron/gate_news X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: sh: /home/m/mailman/scripts/post: Permission denied ----------------------------------------------------------------------- Installed permisions on "post" were: -rw-r--r-- 1 root mailman 2832 Dec 23 14:14 post I did chmod 755 on post and then things started working correctly. From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Dec 24 04:16:46 1998 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 23 Dec 1998 23:16:46 -0500 (EST) Subject: [Mailman-Developers] Problems getting news/mail gateway working (with fixes) References: Message-ID: <13953.49198.383176.471856@anthem.cnri.reston.va.us> Thanks Steve. Actually both this bugs have already been fixed for the next release. You can get the new GatewayManager.py file from the CVS tree (or if it's urgent I can send it to you). -Barry From Harald.Meland@usit.uio.no Wed Dec 30 18:52:55 1998 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 30 Dec 1998 19:52:55 +0100 Subject: [Mailman-Developers] configure not aware of Mailman/pythonlib In-Reply-To: "Barry A. Warsaw"'s message of "Mon, 21 Dec 1998 23:30:54 -0500 (EST)" References: <199812220430.XAA13534@anthem.cnri.reston.va.us> Message-ID: I just braved upgrading from beta 6 to the current CVS version, and got slightly bruised from the fact that configure doesn't know anything about the Mailman/pyhtonlib directory. I think the patch below fixes this (if you run "aclocal; autoconf" after applying it, of course), but then I'm not very familiar with autoconf, so I could be totally wrong :) Index: configure.in =================================================================== RCS file: /projects/cvsroot/mailman/configure.in,v retrieving revision 1.26 diff -u -r1.26 configure.in --- configure.in 1998/11/17 23:49:12 1.26 +++ configure.in 1998/12/30 18:46:51 @@ -364,7 +364,7 @@ AC_OUTPUT([misc/paths.py Mailman/Defaults.py Mailman/mm_cfg.py.dist src/Makefile misc/Makefile bin/Makefile Mailman/Makefile Mailman/Cgi/Makefile Mailman/Logging/Makefile - Mailman/Archiver/Makefile + Mailman/Archiver/Makefile Mailman/pythonlib/Makefile mail/Makefile templates/Makefile cron/Makefile filters/Makefile scripts/Makefile cron/crontab.in Makefile]) -- Harald From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Dec 30 19:08:24 1998 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 30 Dec 1998 14:08:24 -0500 (EST) Subject: [Mailman-Developers] configure not aware of Mailman/pythonlib References: <199812220430.XAA13534@anthem.cnri.reston.va.us> Message-ID: <13962.31272.690202.100002@anthem.cnri.reston.va.us> >>>>> "HM" == Harald Meland writes: HM> I just braved upgrading from beta 6 to the current CVS HM> version, and got slightly bruised from the fact that configure HM> doesn't know anything about the Mailman/pyhtonlib directory. HM> I think the patch below fixes this (if you run "aclocal; HM> autoconf" after applying it, of course), but then I'm not very HM> familiar with autoconf, so I could be totally wrong :) Something's wrong with the CVS mirror because that change should be in the source. It looks like the files didn't get mirrored to the external server... I'm not sure why! I've just done a manual sync, so please try again. I'll try to keep an eye on things to see if the rsync process is failing somehow. Thanks, -Barry From Harald.Meland@usit.uio.no Wed Dec 30 20:02:38 1998 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 30 Dec 1998 21:02:38 +0100 Subject: [Mailman-Developers] configure not aware of Mailman/pythonlib In-Reply-To: "Barry A. Warsaw"'s message of "Wed, 30 Dec 1998 14:08:24 -0500 (EST)" References: <199812220430.XAA13534@anthem.cnri.reston.va.us> <13962.31272.690202.100002@anthem.cnri.reston.va.us> Message-ID: [Barry A. Warsaw] > I've just done a manual sync, so please try again. Done. Things sure look better now :) [ In the hope that it might help you debugging, here are the files that were changed by the update: Makefile.in UPGRADING configure configure.in bin/Makefile.in bin/update doc/LISA-98/README doc/LISA-98/published.ps mail/contact_transport ] -- Harald From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Dec 31 22:54:41 1998 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 31 Dec 1998 17:54:41 -0500 (EST) Subject: [Mailman-Developers] [ANNOUNCE] Mailman 1.0b7 Message-ID: <13964.177.459126.902326@anthem.cnri.reston.va.us> Folks, I've built the tarball for the Mailman 1.0b7 release, however since John appears to be not reading his email during the holiday season, the Web pages at www.list.org have not yet been updated. For now, you can grab the tarball from ftp://ftp.python.org/pub/tmp/mailman-1.0b7.tgz and we'll get the Web site updated ASAP. Below is an excerpt from the DONE file which gives some highlights for this release. My hope is that y'all will bang on this version in the next week or two and, if there are no showstoppers, we can get the full 1.0 release out by mid-January. Given the holiday season, a couple of weeks late isn't so bad! Let me also say that we've got a huge backlog of very good suggestions, contributions, ideas, etc. and on behalf of the other 3 core developers I thank you and encourage you to continue giving feedback. I've spent most of the last 10 days on vacation just trudging through 400-odd messages that I'd accumulated, and I think 1.0b7 fixes most of the really nasty bugs that have been reported up until now. What I haven't done is spend much time adding new features and I don't expect to until after 1.0 final is released. I firmly believe we need to get a stable 1.0 out RRSN, then we can begin to prioritize the new features for 1.1. High on my list is internationalization and an improved Web navigation interface. Longer term, I'm looking at Zope as a possible platform for Mailman. I know John, Ken, and Scott all have their priorities too. Big thanks go to those guys, and especially Scott Cotton, for their work on this release. Enjoy, and have a Happy New Year. -Barry -------------------- snip snip -------------------- 1.0b7 - Many, many bug fixes. Some performance improvements for large lists. Some improvements in the Web interfaces. Some security improvements. Improved compatibility with Python 1.5. - bin/convert_list and bin/populate_new_list have been replaced by bin/add_members. - Admins can now get notification on subscriptions and unsubscriptions. Post are now logged. - The username portion of email addresses are now case-preserved for delivery purposes. All other address comparisions are case-insensitive. - New default SMTP_MAX_RCPTS that limits the number of "RCPT TO" SMTP commands that can be given for a single message. Most MTAs have some hard limit. - "Precedence: bulk" header and "List-id:" header are now added to all outgoing messages. The latter is not added if the message already has a "List-id:" header. See RFC 2046 and draft-chandhok-listid-02 for details. - The standard (as of Python 1.5.2) smtplib.py is now used. - The install process now compiles all the .py files in the installation. - Versions of the Mailman papers given at IPC7 and LISA-98 are now included. From akuchlin@cnri.reston.va.us Tue Dec 1 16:03:49 1998 From: akuchlin@cnri.reston.va.us (Andrew M. Kuchling) Date: Tue, 1 Dec 1998 11:03:49 -0500 (EST) Subject: [Mailman-Developers] Hashing in private.py Message-ID: <13924.4628.294129.257598@amarok.cnri.reston.va.us> I just noticed that the token value used in private.py is just hash(list_name). A simple improvement is to change it to hash(SECRET + list_name) and then change the value of SECRET in private.py. An even better solution would be to do an MD5 hash of SECRET + list_name, but is it OK to assume that the md5 module is present?) (I haven't done a patch for md5 support; let me know if I should.) Also, since setting an archive to private doesn't seem to change the directory where it's archived, this means you have to configure the Web server accordingly. This should be documented somewhere; is it? -- A.M. Kuchling http://starship.skyport.net/crew/amk/ "All we know for sure is that we don't know anything for sure." "That is a particularly foolish thing to say, John Constantine. Light and darkness, life and death. These things are eternally certain." -- John Constantine and Dr Occult, in BOOKS OF MAGIC #1 *** private.py~ Mon Oct 19 16:14:54 1998 --- private.py Tue Dec 1 11:00:06 1998 *************** *** 98,102 **** c = Cookie.Cookie( os.environ['HTTP_COOKIE'] ) if c.has_key(list_name): ! if c[list_name].value == `hash(list_name)`: return 1 # No corresponding cookie. OK, then check for username, password --- 98,102 ---- c = Cookie.Cookie( os.environ['HTTP_COOKIE'] ) if c.has_key(list_name): ! if c[list_name].value == `hash(SECRET + list_name)`: return 1 # No corresponding cookie. OK, then check for username, password *************** *** 129,133 **** return 0 ! token = `hash(list_name)` c = Cookie.Cookie() c[list_name] = token --- 129,133 ---- return 0 ! token = `hash(SECRET + list_name)` c = Cookie.Cookie() c[list_name] = token From troy@akropolys.com Thu Dec 3 05:22:31 1998 From: troy@akropolys.com (Troy Morrison) Date: Wed, 2 Dec 1998 21:22:31 -0800 (PST) Subject: [Mailman-Developers] mailmain + sendmail = "clones" ??? Message-ID: Please forgive my lack of detailed understanding of Python and SendMail, but I'm wondering if anyone has run into this... I've just set up MailMan 1.0b6, and everything is working wonderfully, EXCEPT... after setting up the "test" list, I send a message to "test@host.com", I see the following in the mail logs: Dec 2 20:09:39 sendmail[26787]: UAA26787: from=, size=287, class=0, pri=30287, nrcpts=1, msgid=, proto=ESMTP, relay=troy@localhost Dec 2 20:09:39 enterprise sendmail[26788]: UAA26788: clone UAA26787, owner=test-admin Dec 2 20:09:45 enterprise sendmail[26788]: UAA26788: to="|/home/mailman/mail/wrapper post test", delay=00:00:06, xdelay=00:00:05, mailer=prog, stat=Sent And the message is never delivered to the subscribed parties. Is this something I can change in the sendmail configuration? Or should I punt sendmail in favor of smail/qmail/other MTA? Thanks, Troy From gstein@lyra.org Thu Dec 3 17:51:54 1998 From: gstein@lyra.org (Greg Stein) Date: Thu, 03 Dec 1998 09:51:54 -0800 Subject: [Mailman-Developers] [Fwd: Thread-SIG member |"nouser" bouncing - NOT disabled] Message-ID: <3666CFBA.73DD6888@lyra.org> This is a multi-part message in MIME format. --------------F7A1105FD490855F4A52B7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Note the erroneous "Content-Type:" in the first line of the message body. -g -- Greg Stein, http://www.lyra.org/ --------------F7A1105FD490855F4A52B7 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from ns1.lyra.org (root@ns1.lyra.org [208.192.43.10]) by svpal.svpal.org (8.9.0/8.9.0) with ESMTP id IAA06959 for ; Thu, 3 Dec 1998 08:16:49 -0800 (PST) From: mailman-owner@python.org Received: from python.org (parrot.python.org [132.151.1.90]) by ns1.lyra.org (8.8.5/8.8.5) with ESMTP id IAA00317 for ; Thu, 3 Dec 1998 08:16:12 -0800 Received: from python.org (localhost [127.0.0.1]) by python.org (8.9.1a/8.9.1) with ESMTP id LAA25438 for ; Thu, 3 Dec 1998 11:17:34 -0500 (EST) Received: from python.org (localhost [127.0.0.1]) by python.org (8.9.1a/8.9.1) with ESMTP id LAA25428 for ; Thu, 3 Dec 1998 11:17:29 -0500 (EST) Date: Thu, 3 Dec 1998 11:17:29 -0500 (EST) Message-Id: <199812031617.LAA25428@python.org> Subject: Thread-SIG member |"nouser" bouncing - NOT disabled To: thread-sig-admin@python.org Errors-To: mailman-owner@python.org MIME-version: 1.0 Content-type: multipart/mixed; boundary="132.151.1.90.1.25425.912701849.264.14506" List-Id: SIG on Process Threading in Python X-Mailman-Version: 1.0b7 This MIME message should be readable as plain text. --132.151.1.90.1.25425.912701849.264.14506 Content-type: text/plain; charset=us-ascii This is a Mailman mailing list bounce action notice: List: Thread-SIG Member: |"nouser" Action: Subscription not disabled. Reason: Excessive or fatal bounces. BUT: User not found. The triggering bounce notice is attached below. Questions? Contact the Mailman site administrator at mailman-owner@python.org. --132.151.1.90.1.25425.912701849.264.14506 Content-type: text/plain; charset=us-ascii Received: from koro.off.connect.com.au (koro.off.connect.com.au [192.94.41.1]) by python.org (8.9.1a/8.9.1) with ESMTP id LAA25422 for ; Thu, 3 Dec 1998 11:17:25 -0500 (EST) Received: from localhost (localhost) by koro.off.connect.com.au with internal id DAA20027 (8.8.8/IDA-1.6); Fri, 4 Dec 1998 03:17:02 +1100 (EST) Date: Fri, 4 Dec 1998 03:17:02 +1100 (EST) From: Mail Delivery Subsystem Subject: Returned mail: User unknown Message-ID: <199812031617.DAA20027@koro.off.connect.com.au> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="DAA20027.912701822/koro.off.connect.com.au" Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --DAA20027.912701822/koro.off.connect.com.au The original message was received at Fri, 4 Dec 1998 03:17:00 +1100 (EST) from yarrina.connect.com.au [192.189.54.17] ----- The following addresses had permanent fatal errors ----- |"nouser" (expanded from: nouser) ----- Transcript of session follows ----- This username is no longer valid at connect.com.au. If you have a billing enquiry, please send mail to bills@connect.com.au. If you have a sales enquiry, please send mail to sales@connect.com.au. If you have a support enquiry, please send mail to support@connect.com.au. Alternatively, you can call +61 3 9251 3600. Thankyou. 550 |"nouser"... User unknown --DAA20027.912701822/koro.off.connect.com.au Content-Type: message/delivery-status Reporting-MTA: dns; koro.off.connect.com.au Received-From-MTA: dns; yarrina.connect.com.au Arrival-Date: Fri, 4 Dec 1998 03:17:00 +1100 (EST) Final-Recipient: rfc822; X-Actual-Recipient: rfc822; |nouser@koro.off.connect.com.au Action: failed Status: 5.1.1 Last-Attempt-Date: Fri, 4 Dec 1998 03:17:01 +1100 (EST) --DAA20027.912701822/koro.off.connect.com.au Content-Type: message/rfc822 Return-Path: Received: from yarrina.connect.com.au (yarrina.connect.com.au [192.189.54.17]) by koro.off.connect.com.au with ESMTP id DAA20025 (8.8.8/IDA-1.6); Fri, 4 Dec 1998 03:17:00 +1100 (EST) Received: from python.org (parrot.python.org [132.151.1.90]) by yarrina.connect.com.au with ESMTP id DAA25046 (8.8.8/IDA-1.7); Fri, 4 Dec 1998 03:16:58 +1100 (EST) Received: from python.org (localhost [127.0.0.1]) by python.org (8.9.1a/8.9.1) with ESMTP id LAA25400; Thu, 3 Dec 1998 11:16:33 -0500 (EST) Received: from orinoco.cisco.com (orinoco.cisco.com [171.71.125.34]) by python.org (8.9.1a/8.9.1) with ESMTP id LAA25379 for ; Thu, 3 Dec 1998 11:16:23 -0500 (EST) Received: from scothrel-pc (dhcp-sat-125-165.cisco.com [171.71.125.165]) by orinoco.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with SMTP id KAA06263; Thu, 3 Dec 1998 10:15:19 -0600 (CST) Message-ID: <000801be1ed7$e2d1ba30$a57d47ab@scothrel-pc.cisco.com> From: "Scott Cothrell" To: "Guido VanRossum" Cc: Subject: Re: [Thread-SIG] Re: Losing file output in C Python on NT Date: Thu, 3 Dec 1998 10:13:38 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: thread-sig-admin@python.org List-Id: SIG on Process Threading in Python Errors-To: thread-sig-admin@python.org X-BeenThere: thread-sig@python.org X-Mailman-Version: 1.0b7 >Thanks for posting. I bet this was the "unqualified 'except:' clause" >that I warned you about... Actually, it wasn't. The global except clause was intentional and was/is doing what we wanted. It was a mistyped variable name. > >I have little to comment on the rest of your post -- I'm not sure why >having too many threads would close your sockets, although when the >machine is too heavily loaded, anything can happen -- we've seen this >at CNRI with stress tests from Python as well. We are not at all sure whats going on with the sockets shutting down. The going bet is buffer overflow from too little service time. Its not a big deal since we can tune to it. > >--Guido van Rossum (home page: http://www.python.org/~guido/) > _______________________________________________ Thread-SIG maillist - Thread-SIG@python.org http://www.python.org/mailman/listinfo/thread-sig --DAA20027.912701822/koro.off.connect.com.au-- --132.151.1.90.1.25425.912701849.264.14506-- --------------F7A1105FD490855F4A52B7-- From klm@python.org Thu Dec 3 22:42:16 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 3 Dec 1998 17:42:16 -0500 (EST) Subject: [Mailman-Developers] The bulk issue Message-ID: Can anyone say why we are not putting "Precedence: bulk" on maillist traffic passed by mailman? I seem to recall raising the issue, and having objections, but i'm not recalling the objections, and my yearning to have vacation programs behave like we want (ignoring the messages) is still increasing. So i propose again that we inject our own precedence header iff one is not already there... Ken ---------- Forwarded message ---------- Date: Thu, 3 Dec 1998 14:34:08 -0800 (PST) From: via the vacation program Subject: away from my mail I will be out of the office until Monday December 14. Your email regarding "Re: [Mailman-Users] Compilation problems" will be read when I return. Larry Murdock From akuchlin@cnri.reston.va.us Fri Dec 4 18:22:25 1998 From: akuchlin@cnri.reston.va.us (Andrew M. Kuchling) Date: Fri, 4 Dec 1998 13:22:25 -0500 (EST) Subject: [Mailman-Developers] Patch to private.py Message-ID: <13928.10251.682491.452474@amarok.cnri.reston.va.us> Here's a patch to private.py which makes it 1) return text/plain as the content type if the file ends in .txt, and 2) look for .gz if doesn't exist, and uses the gzip module to read it. -- A.M. Kuchling http://starship.skyport.net/crew/amk/ How do you make sense of your life? Signal to noise: What's signal? What's noise? -- The dying film director in SIGNAL TO NOISE *** private.py 1998/12/04 16:26:29 1.1 --- private.py 1998/12/04 16:48:36 *************** *** 142,145 **** --- 142,149 ---- return path[1:] + def content_type(path): + if path[-3:] == '.gz': path = path[:-3] + if path[-4:] == '.txt': return 'text/plain' + return 'text/html' def main(): *************** *** 147,153 **** true_filename = os.path.join(ROOT, true_path(path) ) list_name = getListName(path) if os.path.isdir(true_filename): true_filename = true_filename + '/index.html' ! if not isAuthenticated(list_name): # Output the password form --- 151,164 ---- true_filename = os.path.join(ROOT, true_path(path) ) list_name = getListName(path) + + # If it's a directory, we have to append index.html in this script. + # We must also check for a gzipped file, because the text archives + # are usually stored in compressed form. if os.path.isdir(true_filename): true_filename = true_filename + '/index.html' ! if (not os.path.exists(true_filename) and ! os.path.exists(true_filename + '.gz') ): ! true_filename = true_filename + '.gz' ! if not isAuthenticated(list_name): # Output the password form *************** *** 167,180 **** print '\n\n', page % vars() sys.exit(0) ! print 'Content-type: text/html\n' ! ! print '\n\n' # Authorization confirmed... output the desired file try: ! f = open(true_filename, 'r') except IOError: print "

Archive File Not Found

" print "No file", path else: while (1): data = f.read(16384) --- 178,196 ---- print '\n\n', page % vars() sys.exit(0) ! # Authorization confirmed... output the desired file try: ! if true_filename[-3:] == '.gz': ! import gzip ! f = gzip.open(true_filename, 'r') ! else: ! f = open(true_filename, 'r') except IOError: + print 'Content-type: text/html\n' + print "

Archive File Not Found

" print "No file", path else: + print 'Content-type:', content_type(path), '\n' while (1): data = f.read(16384) From scott@chronis.pobox.com Fri Dec 4 21:32:53 1998 From: scott@chronis.pobox.com (Scott) Date: Fri, 4 Dec 1998 16:32:53 -0500 Subject: [Mailman-Developers] Hashing in private.py In-Reply-To: <13924.4628.294129.257598@amarok.cnri.reston.va.us>; from Andrew M. Kuchling on Tue, Dec 01, 1998 at 11:03:49AM -0500 References: <13924.4628.294129.257598@amarok.cnri.reston.va.us> Message-ID: <19981204163253.19593@chronis.icgroup.com> It is no more secure to have SECRET defined in the source code than to not have it at all. If anyone is going to spoof a cookie, then looking up the value of secret in the mailman distribution is trivial. While I'm not familiar with the benetits of md5 vs hash (it seems like both would be pretty much equally spoofable, and md5 just involves an extra import but i could be wrong), If we want to protect from cookie spoofing, then there should be a config variable for COOKIE_SECRET or the hash or md5 of the list_name concatenated to the admin site password might work. The point is to make SECRET variable. One potential drawback of md5 is that it can produce characters which need special escaping for http transactions. scott On Tue, Dec 01, 1998 at 11:03:49AM -0500, Andrew M. Kuchling wrote: | I just noticed that the token value used in private.py is just | hash(list_name). A simple improvement is to change it to hash(SECRET | + list_name) and then change the value of SECRET in private.py. An | even better solution would be to do an MD5 hash of SECRET + list_name, | but is it OK to assume that the md5 module is present?) | | (I haven't done a patch for md5 support; let me know if I should.) | | Also, since setting an archive to private doesn't seem to | change the directory where it's archived, this means you have to | configure the Web server accordingly. This should be documented | somewhere; is it? | | -- | A.M. Kuchling http://starship.skyport.net/crew/amk/ | "All we know for sure is that we don't know anything for sure." | "That is a particularly foolish thing to say, John Constantine. Light and | darkness, life and death. These things are eternally certain." | -- John Constantine and Dr Occult, in BOOKS OF MAGIC #1 | | | *** private.py~ Mon Oct 19 16:14:54 1998 | --- private.py Tue Dec 1 11:00:06 1998 | *************** | *** 98,102 **** | c = Cookie.Cookie( os.environ['HTTP_COOKIE'] ) | if c.has_key(list_name): | ! if c[list_name].value == `hash(list_name)`: | return 1 | # No corresponding cookie. OK, then check for username, password | --- 98,102 ---- | c = Cookie.Cookie( os.environ['HTTP_COOKIE'] ) | if c.has_key(list_name): | ! if c[list_name].value == `hash(SECRET + list_name)`: | return 1 | # No corresponding cookie. OK, then check for username, password | *************** | *** 129,133 **** | return 0 | | ! token = `hash(list_name)` | c = Cookie.Cookie() | c[list_name] = token | --- 129,133 ---- | return 0 | | ! token = `hash(SECRET + list_name)` | c = Cookie.Cookie() | c[list_name] = token | | | _______________________________________________ | Mailman-Developers maillist - Mailman-Developers@python.org | http://www.python.org/mailman/listinfo/mailman-developers | From gstein@lyra.org Mon Dec 7 10:10:50 1998 From: gstein@lyra.org (Greg Stein) Date: Mon, 07 Dec 1998 02:10:50 -0800 Subject: [Mailman-Developers] [Fwd: FW: mailman problem?] Message-ID: <366BA9AA.3E366FDB@lyra.org> This is a multi-part message in MIME format. --------------7E6DB674BD75CF9C10E1BE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailman should not present the "Digest: on/off" button when the list is not digestable. Possibly better error handling in general for this. For example, what happens when somebody tries to enable digest via email? Dunno how that would be handled... -g -- Greg Stein, http://www.lyra.org/ --------------7E6DB674BD75CF9C10E1BE Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from ns1.lyra.org (root@ns1.lyra.org [208.192.43.10]) by svpal.svpal.org (8.9.0/8.9.0) with ESMTP id VAA06071 for ; Sun, 6 Dec 1998 21:07:35 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ns1.lyra.org (8.8.5/8.8.5) with ESMTP id VAA00882 for ; Sun, 6 Dec 1998 21:08:39 -0800 Received: by mail2.microsoft.com with Internet Mail Service (5.5.2448.0) id ; Sun, 6 Dec 1998 21:08:47 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100DB90780@RED-MSG-50> From: Bill Tutt To: "'gstein@lyra.org'" Subject: FW: mailman problem? Date: Sun, 6 Dec 1998 21:08:47 -0800 Return-Receipt-To: Bill Tutt X-Mailer: Internet Mail Service (5.5.2448.0) FYI, looks like we hit a bug in mailman. The announce list is correctly configured to be non-digestable sine the traffic level will be very low. Mailman just needs a nice error page. Feel free to look into or forward to Ken, Barry, etc... I'll reply separately to Florent. Bill -----Original Message----- From: florent.heyworth@radbit.com [mailto:florent.heyworth@radbit.com] Sent: Sunday, December 06, 1998 3:45 PM To: Bill Tutt Subject: mailman problem? Hi I suscribed to the p2c-announce list and went on to the "Configuration for p2c-announce" after having sent and received confirmation for the list. I wanted to change the option "Set digest mode" to "on" at: http://mailman.pythonpros.com/mailman/options/p2c- announce/florent.heyworth@radbit.com I received the following error message: (see attachment) Cheers Florent Heyworth *** You better hope the cookie crumbles *** begin 600 ATT636586.txt M/'`^/&@S/E=E)W)E('-O6]U('=O=6QD(&QI:V4@=&\@:&5L<"!U2!T:&4@<')O M8FQE;2P@<&QE87-E#0IE;6%I;"!A(&-O<'D@;V8@=&AI2(L(&QI;F4@,3$R+"!I M;B!397157=O&)I=&UA<"P@:6UA9V4O:G!E9RP@*B\J(#PO=&0^ M/"]T; from Ken Manheimer on Thu, Dec 03, 1998 at 05:42:16PM -0500 References: Message-ID: <19981207034307.H2991@viega.org> I think you're *supposed* to use "Precedence: list" for a mailing list. Might want to check the RFC. On Thu, Dec 03, 1998 at 05:42:16PM -0500, Ken Manheimer wrote: > Can anyone say why we are not putting "Precedence: bulk" on maillist > traffic passed by mailman? I seem to recall raising the issue, and > having objections, but i'm not recalling the objections, and my yearning > to have vacation programs behave like we want (ignoring the messages) is > still increasing. So i propose again that we inject our own precedence > header iff one is not already there... > > Ken > > ---------- Forwarded message ---------- > Date: Thu, 3 Dec 1998 14:34:08 -0800 (PST) > From: via the vacation program > Subject: away from my mail > > I will be out of the office until Monday December 14. > Your email regarding > > "Re: [Mailman-Users] Compilation problems" > > will be read when I return. > > Larry Murdock > > > > > _______________________________________________ > Mailman-Developers maillist - Mailman-Developers@python.org > http://www.python.org/mailman/listinfo/mailman-developers From Brian@digicool.com Tue Dec 8 15:07:04 1998 From: Brian@digicool.com (Brian Lloyd) Date: Tue, 8 Dec 1998 10:07:04 -0500 Subject: [Mailman-Developers] 1.0b6 password cmd bug report Message-ID: <613145F79272D211914B0020AFF64019FC8E@gandalf.digicool.com> It seems that 1.0b6 doesnt correctly handle the password command via email: from MailCommandHandler.py: def ProcessPasswordCmd(self, args, cmd, mail): if len(args) <> 2: self.AddError("Usage: password ") return try: self.ChangeUserPassword(mail.GetSender(), args[0], args[1], args[1]) self.AddToResponse('Succeeded.') ProcessPasswordCmd is calling ChangeUserPassword with too many arguments, causing a TypeError: from SecurityManager.py: def ChangeUserPassword(self, user, newpw, confirm): self.IsListInitialized() Brian Lloyd brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com From akuchlin@cnri.reston.va.us Tue Dec 8 15:21:15 1998 From: akuchlin@cnri.reston.va.us (Andrew M. Kuchling) Date: Tue, 8 Dec 1998 10:21:15 -0500 (EST) Subject: [Mailman-Developers] Bug (?) report from Paul Everitt Message-ID: <13933.17329.597791.426465@amarok.cnri.reston.va.us> --UyqdjfJ7sY Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I don't know if anyone on this list is following the Zope mailing list, so just in case: Paul Everitt ran into the following problem. Can anyone offer a clue? -- A.M. Kuchling http://starship.skyport.net/crew/amk/ Good job, there, O'Grady. Always kick 'em when they're down. You might just make a detective yet. -- Lt. Burke, in SANDMAN MYSTERY THEATRE: "The Cannon", act IV --UyqdjfJ7sY Content-Type: message/rfc822 Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by newcnri.cnri.reston.va.us (8.9.1a/8.9.1) with SMTP id KAA26672; Tue, 8 Dec 1998 10:17:15 -0500 (EST) Received: from albert.digicool.com (albert.digicool.com [206.156.192.156]) by cnri.reston.va.us (8.9.1a/8.9.1) with ESMTP id KAA10543; Tue, 8 Dec 1998 10:17:03 -0500 (EST) Received: from albert.digicool.com (localhost [127.0.0.1]) by albert.digicool.com (8.9.1/8.9.1) with ESMTP id KAA11798; Tue, 8 Dec 1998 10:16:19 -0500 Received: from gandalf.digicool.com (gandalf.digicool.com [206.156.192.144]) by albert.digicool.com (8.9.1/8.9.1) with ESMTP id KAA11773 for ; Tue, 8 Dec 1998 10:16:02 -0500 Received: by gandalf.digicool.com with Internet Mail Service (5.5.1960.3) id ; Tue, 8 Dec 1998 10:19:33 -0500 Message-ID: <613145F79272D211914B0020AFF640192E24@gandalf.digicool.com> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) List-Id: Zope -- The Z Object Publishing Environment Errors-To: zope-admin@zope.org X-BeenThere: zope@zope.org X-Mailman-Version: 1.0b6 Content-Type: text/plain Content-Length: 1894 From: Paul Everitt Sender: zope-admin@zope.org To: "Dinu C. Gherman" , Joachim Schmitz Cc: zope@zope.org Subject: RE: [Zope] - Re: trying to subscribe Date: Tue, 8 Dec 1998 10:19:31 -0500 Dinu wrote: > Joachim wrote: > >I tried it in the subject-line, in the body, in body and > > subjectline no > >response. > > > It worked for me, but - another problem - I can't set > the digest option, at least not by sending an email to > zope-request@... (haven't tried yet over HTTP), although > MailMan said my new settings were fine. > > Maybe MailMan is not yet fully operational? I get the Mailman admin messages and I've been getting a number of complaints from it. Perhaps someone here can help me with Mailman? (I _really_ need to subscribe to the Mailman list!) --------------------------------------------- **** Subject line ignored: Returned mail: Host unknown (Name server: paradise.mgs.net: host not found) >>>> This is a MIME-encapsulated message **** this: Command UNKNOWN. >>>> --XAA09335.913093181/albert.digicool.com **** --xaa09335.913093181/albert.digicool.com: Command UNKNOWN. >>>> The original message was received at Mon, 7 Dec 1998 23:59:41 -0500 **** the: Command UNKNOWN. >>>> from localhost [127.0.0.1] **** from: Command UNKNOWN. >>>> ----- The following addresses had permanent fatal errors ----- **** -----: Command UNKNOWN. --------------------------------------------------------- Here's the one for digests: Traceback (innermost last): File "/home/mailman/cron/senddigests", line 37, in ? main() File "/home/mailman/cron/senddigests", line 34, in main list.SendDigestIfAny() File "/home/mailman/Mailman/Digester.py", line 194, in SendDigestIfAny self.SendDigestOnSize(0) File "/home/mailman/Mailman/Digester.py", line 206, in SendDigestOnSize self.SendDigest() File "/home/mailman/Mailman/Digester.py", line 288, in SendDigest self.DeliverToList(d.Present(mime=0), File "/home/mailman/Mailman/Deliverer.py", line 133, in DeliverToList status = cmdproc.close() IOError: (10, 'No child processes') --Paul --UyqdjfJ7sY-- From klm@python.org Wed Dec 9 17:05:51 1998 From: klm@python.org (Ken Manheimer) Date: Wed, 9 Dec 1998 12:05:51 -0500 (EST) Subject: [Mailman-Developers] 1.0b6 password cmd bug report In-Reply-To: <613145F79272D211914B0020AFF64019FC8E@gandalf.digicool.com> Message-ID: On Tue, 8 Dec 1998, Brian Lloyd wrote: > It seems that 1.0b6 doesnt correctly handle the > password command via email: > > from MailCommandHandler.py: > > def ProcessPasswordCmd(self, args, cmd, mail): > if len(args) <> 2: > self.AddError("Usage: password ") > return > try: > self.ChangeUserPassword(mail.GetSender(), > args[0], args[1], args[1]) > self.AddToResponse('Succeeded.') > > > ProcessPasswordCmd is calling ChangeUserPassword with > too many arguments, causing a TypeError: > > from SecurityManager.py: > > def ChangeUserPassword(self, user, newpw, confirm): > self.IsListInitialized() Thanks for pinpointing the trouble location! I've checked in a fix - in case you're interested, the problem was that ChangeUserPassword() was being invoked as if it validated the old password and then took the new password and it's verification copy, when in fact a separate function must be used to do the old password validation. I checked in the new version of the file to the cvs tree (and fixed a problem with the CVS update mechanism, so that the public tree is now up to date - it somehow got broken, and was out of sync for a few days). In case you just want the relevant lines of code, substitute the following lines for "try:" line in the code you cited in MailCommandHandler.py: sender = mail.GetSender() try: self.ConfirmUserPassword(sender, args[0]) (Using this instead of updating from the repository will lead to some redundant calls to mail.GetSender(), but that has negligible effect.) Ken From klm@python.org Fri Dec 11 00:10:29 1998 From: klm@python.org (Ken Manheimer) Date: Thu, 10 Dec 1998 19:10:29 -0500 (EST) Subject: [Mailman-Developers] Exactly 100 subscribers on mailman-users@python.org Message-ID: <13936.25138.715614.637686@glyph.cnri.reston.va.us> I just happened to notice that there are exactly 100 subscribers to mailman-users. Besides admiring the nice, round number, it also occurred to me that it may be interesting to see how the number changes after john gives the presentation tomorrow at Usenix... Ken From gstein@lyra.org Thu Dec 17 00:15:28 1998 From: gstein@lyra.org (Greg Stein) Date: Wed, 16 Dec 1998 16:15:28 -0800 Subject: [Mailman-Developers] patch to subscribeack.txt Message-ID: <36784D20.56B10AC@lyra.org> I received a report that the welcome message is slightly misleading. I changed a couple lines in the middle to read: with the word "help" in the subject or body (don't add the quotes), and you will get back a message with instructions. Cheers, -g -- Greg Stein, http://www.lyra.org/ From klm@python.org Thu Dec 17 00:16:25 1998 From: klm@python.org (Ken Manheimer) Date: Wed, 16 Dec 1998 19:16:25 -0500 (EST) Subject: [Mailman-Developers] patch to subscribeack.txt In-Reply-To: <36784D20.56B10AC@lyra.org> Message-ID: On Wed, 16 Dec 1998, Greg Stein wrote: > I received a report that the welcome message is slightly misleading. I > changed a couple lines in the middle to read: > > with the word "help" in the subject or body (don't add the quotes), > and you will get back a message with instructions. Thanks - i happened to be editing another template, and it'll be a while until i could check in the changes, so i satisfied my checkin urges (hopefully enough to satisfy my "finish something today" compulsion to let me go home and get dinner:-) and applied your change. Um, don't expect this kind of turnaround in the future.-) :-) ken From gstein@lyra.org Thu Dec 17 23:31:14 1998 From: gstein@lyra.org (Greg Stein) Date: Thu, 17 Dec 1998 15:31:14 -0800 Subject: [Mailman-Developers] Deliverer.py Message-ID: <36799442.38D5A4C4@lyra.org> Two items that I noticed in Deliverer.py: 1) it writes to stderr, rather than logging 2) the writes do not have a final newline Cheers, -g -- Greg Stein, http://www.lyra.org/ From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Dec 18 05:14:47 1998 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 18 Dec 1998 00:14:47 -0500 (EST) Subject: [Mailman-Developers] Deliverer.py References: <36799442.38D5A4C4@lyra.org> Message-ID: <13945.58567.449227.63965@anthem.cnri.reston.va.us> >>>>> "GS" == Greg Stein writes: GS> Two items that I noticed in Deliverer.py: | 1) it writes to stderr, rather than logging | 2) the writes do not have a final newline Thanks Greg. Both of these are easily fixed by calling self.LogMsg() instead of sys.stderr.write(). -Barry From grin@tolna.net Fri Dec 18 10:41:32 1998 From: grin@tolna.net (Peter Gervai) Date: Fri, 18 Dec 1998 11:41:32 +0100 Subject: [Mailman-Developers] debug logging, long CC (Deliverer.py) In-Reply-To: <36799442.38D5A4C4@lyra.org>; from Greg Stein on Thu, Dec 17, 1998 at 03:31:14PM -0800 References: <36799442.38D5A4C4@lyra.org> Message-ID: <19981218114132.C12496@mail.tolna.net> On Thu, Dec 17, 1998 at 03:31:14PM -0800, Greg Stein wrote: > Two items that I noticed in Deliverer.py: > > 1) it writes to stderr, rather than logging This reminds me to the feeling when I first met mailman, when I thought: uhh, this program cannot log anything. I don't see what happens. There is some logfiles, but apart from the error log (which doesn't help always so well :)) there is no useful logfile. Is there a log for all processed messages for example? Especially the subscribe and confirmation messages? The bounces mailman processes, and other non-fatal errors? Maybe there is a possibility to have debug log but I didn't find it. It was especially sad when I put a larger list to mailman and found out that LOTS of mail did not get delivered, and there were NO sign anywhere in the logs that 1) delivery did not happen 2) why it did not happen. The other question is the reason why it didnt: it was because mailman wanted to send a mail with a very long CC list, and because security reasons the CC's were maxed at 15, so delivery failed with 5xx error somewhere in the middle and mail got silently lost. Is there any settings to set how many CC's mailman will use at most? At least it should later be documented somewhere that mailman requires such limitations lifted. best regards, grin From boldi@budapest.hu Fri Dec 18 22:11:23 1998 From: boldi@budapest.hu (Bencsath Boldizsar) Date: Fri, 18 Dec 1998 23:11:23 +0100 (CET) Subject: [Mailman-Developers] small sec problem / or feuture (?) Message-ID: Hi, I am not list member, but didn't find any bugreport address in the docs of mailman ( please make one.. :) ) So, in 1.0b6 there is a small problem: Pendig messages can be seen by anyone / i didn't checked the privacy options, but it's more logical, that pending messages are only viewable by the admin through the password. check http://www.anything.something/mailman/admindb/ boldi -------------------------------- Bencsath Boldizsar boldi@inf.bme.hu boldi@rulez.org greetings to mol S.A.I.C. VIP Protection SASSTIXS http://www.inf.bme.hu/~boldi -------------------------------- From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Dec 19 04:38:44 1998 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 18 Dec 1998 23:38:44 -0500 (EST) Subject: [Mailman-Developers] small sec problem / or feuture (?) References: Message-ID: <13947.11732.567166.584256@anthem.cnri.reston.va.us> >>>>> "BB" == Bencsath Boldizsar writes: BB> Hi, I am not list member, but didn't find any bugreport BB> address in the docs of mailman ( please make one.. :) ) mailman-developers@python.org is fine. I've added a note to the BUGS file. BB> So, in 1.0b6 there is a small problem: Pendig messages can be BB> seen by anyone / i didn't checked the privacy options, but BB> it's more logical, that pending messages are only viewable by BB> the admin through the password. check BB> http://www.anything.something/mailman/admindb/ boldi Good point. I think doing the admin authentication upfront is better for dealing with pending messages too. I've got this working and will check it in for the next release. Thanks, -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Dec 19 05:21:34 1998 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 19 Dec 1998 00:21:34 -0500 (EST) Subject: [Mailman-Developers] debug logging, long CC (Deliverer.py) References: <36799442.38D5A4C4@lyra.org> <19981218114132.C12496@mail.tolna.net> Message-ID: <13947.14302.507778.960606@anthem.cnri.reston.va.us> >>>>> "PG" == Peter Gervai writes: PG> This reminds me to the feeling when I first met mailman, when PG> I thought: uhh, this program cannot log anything. I don't see PG> what happens. There is some logfiles, but apart from the error PG> log (which doesn't help always so well :)) there is no useful PG> logfile. Is there a log for all processed messages for PG> example? Especially the subscribe and confirmation messages? PG> The bounces mailman processes, and other non-fatal errors? Lots of stuff should be getting logged, but I can't remember what's in 1.0b6 (Ken?). You should see every post getting logged, subscribes/unsubscribes, digests, and of course errors. The error logging ought to be very helpful if you're trying to track down a Mailman bug (but there are none any of *those* right?! :-). I'm sure there's more we could log though. PG> Maybe there is a possibility to have debug log but I didn't PG> find it. It was especially sad when I put a larger list to PG> mailman and found out that LOTS of mail did not get delivered, PG> and there were NO sign anywhere in the logs that 1) delivery PG> did not happen 2) why it did not happen. You don't say what version of Mailman you're using. There are a couple of places that bugs can happen to prevent message delivery. If it happens in the mail wrapper binary (e.g. you got your mail-gid wrong), you'll need to enable syslog to catch those, since they don't make it to Python yet. If the error happens within the Python part of Mailman, you should see those in the error log. Same with CGI. The error logs (for CGI) should be quite complete; they should contain the Python traceback pointing you right to the source line that crapped out, along with a dump of the environment variables the CGI script saw. PG> The other question is the reason why it didnt: it was because PG> mailman wanted to send a mail with a very long CC list, and PG> because security reasons the CC's were maxed at 15, so PG> delivery failed with 5xx error somewhere in the middle and PG> mail got silently lost. Is there any settings to set how many PG> CC's mailman will use at most? At least it should later be PG> documented somewhere that mailman requires such limitations PG> lifted. Look in the Privacy Options. There's an option that says "Ceiling on acceptable number of recipients for a posting". This defaults to 10. BTW, if this is really why the messages are not being delivered, they probably aren't just lost. They get held for administrative approval for a period of time. Check the pending messages for the list. Hope that helps, -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Dec 19 06:13:08 1998 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 19 Dec 1998 01:13:08 -0500 (EST) Subject: [Mailman-Developers] The bulk issue References: <19981207034307.H2991@viega.org> Message-ID: <13947.17396.643301.995943@anthem.cnri.reston.va.us> >>>>> "JV" == John Viega writes: JV> I think you're *supposed* to use "Precedence: list" for a JV> mailing list. Might want to check the RFC. I'm not finding this in the docs I've consulted, RFC 2076 and its Jan-1998 update: http://www.dsv.su.se/~jpalme/ietf/ietf-mail-attributes.html Looks like Precedence: bulk is as close as it gets. Interesting enough, we don't add this to posted messages, but we *do* add this to emailed passwords. I'll try to add this, and (maybe) other list related headers referred to in the document. -Barry From klm@python.org Sat Dec 19 06:45:40 1998 From: klm@python.org (Ken Manheimer) Date: Sat, 19 Dec 1998 01:45:40 -0500 (EST) Subject: [Mailman-Developers] The bulk issue In-Reply-To: <13947.17396.643301.995943@anthem.cnri.reston.va.us> Message-ID: On Sat, 19 Dec 1998, Barry A. Warsaw wrote: > >>>>> "JV" == John Viega writes: > > JV> I think you're *supposed* to use "Precedence: list" for a > JV> mailing list. Might want to check the RFC. > > I'm not finding this in the docs I've consulted, RFC 2076 and its > Jan-1998 update: > > http://www.dsv.su.se/~jpalme/ietf/ietf-mail-attributes.html > > Looks like Precedence: bulk is as close as it gets. Interesting > enough, we don't add this to posted messages, but we *do* add this to > emailed passwords. I'll try to add this, and (maybe) other list > related headers referred to in the document. I actually did look it over a bit, and from RFC 822 (or somesuch) it sounds like precedence: bulk has a dubious pedegree. More importantly, after reviewing the vacation man page, i realized that the precedence: bulk header would be redundant for mailing list traffic, since most of the kinds of things that respect it also refrain from responding to messages that do not have the recipient's address explicitly mentioned among the destination addresses, which is inherently the case for maillist traffic - so the precedence: bulk is unnecessary. (I should have mentioned this when i originally realized this.) So i'm not sure adding precedence bulk is a good idea. The password reminders (and other administrative messages) are another matter, because they are directed to specific individuals. I actually added the precedence: bulk to the password reminders in a mad scramble just before the end of last month - the scramble was because i *dreaded* the deluge of vacation-message responses i was getting, as mailman-owner, from the python.org mailing list mass reminders delivery... Ken From roy@endeavor.med.nyu.edu Sat Dec 19 12:35:53 1998 From: roy@endeavor.med.nyu.edu (Roy Smith) Date: Sat, 19 Dec 1998 07:35:53 -0500 Subject: [Mailman-Developers] routing loop circuit breakers In-Reply-To: <13947.17396.643301.995943@anthem.cnri.reston.va.us> Message-ID: <136508.3123041753@mcsv29-p2.med.nyu.edu> We just had a mail routing loop disaster on one of our mailing lists (not run with mailmail). A list subscriber had a mis-behaved vacation responder which flooded the list with about 100 copies of a vacation message in the course of a couple of hours before it got noticed. You can imagine the mess this caused. Does mailman have any soft of circuit breaker to prevent something like this? If so, it would probably be the incentive we need to change from majordomo to mailman. I guess the right heuristic to have prevented this would be something like refusing mail from anybody if they have sent more than N messages in X minutes. I could even imagine a fast-blow and slow-blow threshold, i.e. "5 messages in 10 minutes or 20 messages in 24 hours" type of thing. Is this possible? Roy Smith New York University School of Medicine 550 First Avenue, New York, NY 10016 From Harald.Meland@usit.uio.no Sat Dec 19 15:00:36 1998 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 19 Dec 1998 16:00:36 +0100 Subject: [Mailman-Developers] The bulk issue In-Reply-To: Ken Manheimer's message of "Sat, 19 Dec 1998 01:45:40 -0500 (EST)" References: Message-ID: [Ken Manheimer] > More importantly, after reviewing the vacation man page, i realized > that the precedence: bulk header would be redundant for mailing list > traffic, since most of the kinds of things that respect it also > refrain from responding to messages that do not have the recipient's > address explicitly mentioned among the destination addresses, which > is inherently the case for maillist traffic - so the precedence: > bulk is unnecessary. I'd say inserting a "Precedence: list" header is a good thing anyway. Consider the case of a vacation program not knowing which addresses maps to which mail users -- such a vacation program (which is not at all uncommon) would have (very nearly) no idea whether the address in the To: header is a mailing list address or some strange alias pointing to the mail user it is trying to do it's thing for. Giving such a vacation program an additional header to base it's judgement on is IMHO a good thing. I have no idea where, or even if, "Precedence: list" is standardized in any way, but I think that thath is what majordomo is inserting. Being compatible with majordomo when it doesn't cost us anything is also, IMHO, a good thing. The only reason I see for _not_ adding any Precedence: header, is that Mailman-delivered messages have half a truckload of headers as it is. But that, IMHO, isn't really a strong argument -- as long as all the headers are there for some good reason, they _should_ be in there. Just my ¤.02, -- Harald From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Dec 19 20:35:49 1998 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 19 Dec 1998 15:35:49 -0500 (EST) Subject: [Mailman-Developers] The bulk issue References: <13947.17396.643301.995943@anthem.cnri.reston.va.us> Message-ID: <13948.3621.659652.961983@anthem.cnri.reston.va.us> >>>>> "KM" == Ken Manheimer writes: KM> So i'm not sure adding precedence bulk is a good idea. Already, I suppose we can forget it, even though it would be trivial to add. I think you've got the right trade-off. I do want to look at adding the other IETF draft mailinglist headers, and may look into that. -Barry From grin@tolna.net Sat Dec 19 20:36:07 1998 From: grin@tolna.net (Peter Gervai) Date: Sat, 19 Dec 1998 21:36:07 +0100 Subject: [Mailman-Developers] debug logging, long CC (Deliverer.py) In-Reply-To: <13947.14302.507778.960606@anthem.cnri.reston.va.us>; from Barry A. Warsaw on Sat, Dec 19, 1998 at 12:21:34AM -0500 References: <36799442.38D5A4C4@lyra.org> <19981218114132.C12496@mail.tolna.net> <13947.14302.507778.960606@anthem.cnri.reston.va.us> Message-ID: <19981219213607.B11937@mail.tolna.net> Barry, On Sat, Dec 19, 1998 at 12:21:34AM -0500, Barry A. Warsaw wrote: > > >>>>> "PG" == Peter Gervai writes: > > PG> This reminds me to the feeling when I first met mailman, when > PG> I thought: uhh, this program cannot log anything. I don't see > PG> what happens. There is some logfiles, but apart from the error > PG> log (which doesn't help always so well :)) there is no useful > PG> logfile. Is there a log for all processed messages for > PG> example? Especially the subscribe and confirmation messages? > PG> The bounces mailman processes, and other non-fatal errors? > > Lots of stuff should be getting logged, but I can't remember what's in > 1.0b6 (Ken?). You should see every post getting logged, > subscribes/unsubscribes, digests, and of course errors. No, definitely I completely miss the logfile showing the posts. Subscribes/unsubs get logged as well as errors, though error log a bit hard to use because it doesn't show the variables failed. > The error > logging ought to be very helpful if you're trying to track down a > Mailman bug (but there are none any of *those* right?! :-). Hehe, don't tell me, I'm that guy with the exim and the questions about permissions nobody was able to answer, as well as error messages being unfamiliar to anyone. :-) > PG> Maybe there is a possibility to have debug log but I didn't > PG> find it. It was especially sad when I put a larger list to > PG> mailman and found out that LOTS of mail did not get delivered, > PG> and there were NO sign anywhere in the logs that 1) delivery > PG> did not happen 2) why it did not happen. > > You don't say what version of Mailman you're using. There are a Sorry, trying to be at the lastest released, this time 1.0b6. I realized that I had a new logfile, namely smtp-failures. :-) It shows at least the error message caused the delivery to fail. Nice. > PG> The other question is the reason why it didnt: it was because > PG> mailman wanted to send a mail with a very long CC list, and > PG> because security reasons the CC's were maxed at 15, so > PG> delivery failed with 5xx error somewhere in the middle and > PG> mail got silently lost. Is there any settings to set how many > PG> CC's mailman will use at most? At least it should later be > PG> documented somewhere that mailman requires such limitations > PG> lifted. > > Look in the Privacy Options. There's an option that says "Ceiling on > acceptable number of recipients for a posting". This defaults to 10. It's been 10 by default. Doesn't seem to matter at all. > BTW, if this is really why the messages are not being delivered, they > probably aren't just lost. They get held for administrative approval > for a period of time. Check the pending messages for the list. Of course I regularly check the waiting messages as I'm the owner as well but there were none waiting, obviosuly. The message got delivered to the small batch (outside users, 3 cc) and lost for the big one (local users, 20-50 cc)... thank you, grin From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Sat Dec 19 20:42:15 1998 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Sat, 19 Dec 1998 15:42:15 -0500 (EST) Subject: [Mailman-Developers] The bulk issue References: Message-ID: <13948.4007.271847.853690@anthem.cnri.reston.va.us> >>>>> "HM" == Harald Meland writes: HM> I have no idea where, or even if, "Precedence: list" is HM> standardized in any way, but I think that thath is what HM> majordomo is inserting. Being compatible with majordomo when HM> it doesn't cost us anything is also, IMHO, a good thing. As far as I can tell, it is not documented anywhere; not even in the update to RFC 2076. I'll see if I can search around in Majordomo to see what they do, but if anybody else can verify this, it would be helpful. HM> The only reason I see for _not_ adding any Precedence: header, HM> is that Mailman-delivered messages have half a truckload of HM> headers as it is. But that, IMHO, isn't really a strong HM> argument -- as long as all the headers are there for some good HM> reason, they _should_ be in there. Yeah, and the IETF draft adds 9 more headers ;-( -Barry From klm@python.org Sat Dec 19 21:33:44 1998 From: klm@python.org (Ken Manheimer) Date: Sat, 19 Dec 1998 16:33:44 -0500 (EST) Subject: [Mailman-Developers] debug logging, long CC (Deliverer.py) In-Reply-To: <19981219213607.B11937@mail.tolna.net> Message-ID: On Sat, 19 Dec 1998, Peter Gervai wrote: > Barry, > > On Sat, Dec 19, 1998 at 12:21:34AM -0500, Barry A. Warsaw wrote: > > > > >>>>> "PG" == Peter Gervai writes: > > > > PG> This reminds me to the feeling when I first met mailman, when > > PG> I thought: uhh, this program cannot log anything. I don't see > > PG> what happens. There is some logfiles, but apart from the error > > PG> log (which doesn't help always so well :)) there is no useful > > PG> logfile. Is there a log for all processed messages for > > PG> example? Especially the subscribe and confirmation messages? > > PG> The bounces mailman processes, and other non-fatal errors? > > > > Lots of stuff should be getting logged, but I can't remember what's in > > 1.0b6 (Ken?). You should see every post getting logged, > > subscribes/unsubscribes, digests, and of course errors. > > No, definitely I completely miss the logfile showing the posts. > Subscribes/unsubs get logged as well as errors, though error log > a bit hard to use because it doesn't show the variables failed. Logging of posts is in the "frontier" (CVS repository) version, soon to be released as 1.0b7. (It was added by scott cotton, not too long after 1.0b6 was released.) I should add that i was surprised to see you say "this program cannot log anything". We don't pretend Mailman is perfect, but it's discouraging to hear such low judgements ("no useful logfile"), particularly about things we're working on improving (and about which you seem to be mistaken - we've had logs for both subscribe and bounce activity for a while!) I agree that it would be nice to be able to glean more about the specific coding errors from the error log - but we're mostly dealing with the limits of the resolution of Python tracebacks, here. This actually is something that is improving in Python (due to some recent work by barry!), and in general i expect the situation to progressively improve. (I've added to the todo list that error messages should say more about failed file, maillist, etc identities.) > > PG> The other question is the reason why it didnt: it was because > > PG> mailman wanted to send a mail with a very long CC list, and > > PG> because security reasons the CC's were maxed at 15, so > > PG> delivery failed with 5xx error somewhere in the middle and > > PG> mail got silently lost. Is there any settings to set how many > > PG> CC's mailman will use at most? At least it should later be > > PG> documented somewhere that mailman requires such limitations > > PG> lifted. > > > > Look in the Privacy Options. There's an option that says "Ceiling on > > acceptable number of recipients for a posting". This defaults to 10. > > It's been 10 by default. Doesn't seem to matter at all. There is a serious architectural obstacle for delivery failures that occur for destinations on the local system - because the MTA doesn't generate any bounce messages in that case. This is something that should be corrected in our smtplib (i'm not sure whether the interface in the standard python smtplib addresses the problem, either), but at least the smtp-failures log file should register the problem. That said, once again the frontier version has a fix for your particular problem (once again, from scott cotton). It's in the form of a new parameter, SMTP_MAX_RCPTS, which constrains the size of the groups into which destinations are batched for delivery. You should be able to set that to 10, or whatever, and prevent your MTA from getting passed batches larger than 10. This will probably reduce the speed of the delivery process, but that sounds like a tradeoff that your site has elected for, in general. > > BTW, if this is really why the messages are not being delivered, they > > probably aren't just lost. They get held for administrative approval > > for a period of time. Check the pending messages for the list. > > Of course I regularly check the waiting messages as I'm the owner as well > but there were none waiting, obviosuly. The message got delivered to the > small batch (outside users, 3 cc) and lost for the big one (local > users, 20-50 cc)... I'm really suspecting you're not talking about addresses in the CC headers, but rather groups into which deliveries for the list were batched. Sorry if i'm mistaken - if i am, we'll need more info to determine why the size-of-cc-option is failing for you... Ken Manheimer klm@python.org 703 620-8990 x268 (orporation for National Research |nitiatives # If you appreciate Python, consider joining the PSA! # # . # From grin@tolna.net Sat Dec 19 22:49:55 1998 From: grin@tolna.net (Peter Gervai) Date: Sat, 19 Dec 1998 23:49:55 +0100 Subject: [Mailman-Developers] debug logging, long CC (Deliverer.py) In-Reply-To: ; from Ken Manheimer on Sat, Dec 19, 1998 at 04:33:44PM -0500 References: <19981219213607.B11937@mail.tolna.net> Message-ID: <19981219234955.E11937@mail.tolna.net> Ken, > > > PG> This reminds me to the feeling when I first met mailman, when > > > PG> I thought: uhh, this program cannot log anything. I don't see [...] > I should add that i was surprised to see you say "this program cannot > log anything". We don't pretend Mailman is perfect, but it's > discouraging to hear such low judgements ("no useful logfile"), Oh, sorry if I sounded like that, it wasn't intentional! I wanted to tell about when I was young and ingorant to the great aspects of mailman, and when I first saw it (and the next 397 times when I tried to get it started in my brainwashed environment) I felt the miss of the detailed logfiles about what happens. But of course since I managed it to work fine I don't feel the miss. I just think others might need them in the startup phase, at least until the program gets rid of that 'b' from the version number. :-) I think I state the obvious when mentioning that even I avoid Python I've fallen in love with mailman as it not only manages lists, but do it with a royal superiority. :) The UI is very useful, pretty; the bounce detection is wise, and the admin UI is easy to use. Bugreports and (uncalled) complaints always sound a bit disappointing, maybe I'll try to put some "you know that we love mailman and that's why we make such bugreports" :) to make you feel it's not because I think it's BAD but because I want it to be BETTER. Better than best, you see. :) > particularly about things we're working on improving (and about which > you seem to be mistaken - we've had logs for both subscribe and bounce > activity for a while!) Apologies for not mentioning those logs, but at least I never mentioned they doesn't exist. :) > I agree that it would be nice to be able to glean more about the > specific coding errors from the error log - but we're mostly dealing > with the limits of the resolution of Python tracebacks, here. This I don't know Python that deep enough, I just suspected that being an interpreted language it could evaluate the line in question so find variables in the line in question and tell their values... Maybe this only shows my lack of Pythonness. :) > > > PG> The other question is the reason why it didnt: it was because > > > PG> mailman wanted to send a mail with a very long CC list, and [...] > > > Look in the Privacy Options. There's an option that says "Ceiling on > > > acceptable number of recipients for a posting". This defaults to 10. > > > > It's been 10 by default. Doesn't seem to matter at all. > > There is a serious architectural obstacle for delivery failures that > occur for destinations on the local system - because the MTA doesn't > generate any bounce messages in that case. This is something that > should be corrected in our smtplib (i'm not sure whether the interface > in the standard python smtplib addresses the problem, either), but at > least the smtp-failures log file should register the problem. Unfortunately that was quite hard to spot... If I weren't in the batch disappearing I'd never see there was a problem at all. > > Of course I regularly check the waiting messages as I'm the owner as well > > but there were none waiting, obviosuly. The message got delivered to the > > small batch (outside users, 3 cc) and lost for the big one (local > > users, 20-50 cc)... > > I'm really suspecting you're not talking about addresses in the CC > headers, but rather groups into which deliveries for the list were > batched. Sorry if i'm mistaken - if i am, we'll need more info to > determine why the size-of-cc-option is failing for you... I can't really tell you whether it's CC or multiple RCPT TO: fields since I don't have the logfile :-)) But I'm confident that the error was caused by having a limit on the number of recipients a single mail can contain, no matter the method. (Posted mail did not contain any cc at all, if that was your question.) To mailman limited numbers of CC could mean a tradeoff (more batches) but efficiently stops ignorant users from creating mass-mailings. In these times we live in this do matter. bye, grin From Harald.Meland@usit.uio.no Sun Dec 20 13:25:27 1998 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 20 Dec 1998 14:25:27 +0100 Subject: [Mailman-Developers] The bulk issue In-Reply-To: "Barry A. Warsaw"'s message of "Sat, 19 Dec 1998 15:42:15 -0500 (EST)" References: <13948.4007.271847.853690@anthem.cnri.reston.va.us> Message-ID: [Barry A. Warsaw] > >>>>> "HM" == Harald Meland writes: > > HM> I have no idea where, or even if, "Precedence: list" is > HM> standardized in any way, but I think that thath is what > HM> majordomo is inserting. Being compatible with majordomo when > HM> it doesn't cost us anything is also, IMHO, a good thing. > > As far as I can tell, it is not documented anywhere; not even in the > update to RFC 2076. Sorry, my mistake. I should have said "Due to the behaviour I am seeing on some of the majordomo lists I am on, I think that majordomo inserts `Precedence: list' headers." Now that I have actually done some grepping of the majordomo source, I can't find anything in majordomo 1.94.4 which should cause the precedence header to default to anything but "bulk". Thus, I agree that inserting "Precedence: list" as a default seems inappropriate. However, I believe that not inserting any Precedence: header *at*all* will cause trouble. My example (the vacation program which doesn't know the mapping between local users and local addresses) was meant to show that inserting *a* Precedence: header would be useful. > I'll see if I can search around in Majordomo to see what they do, > but if anybody else can verify this, it would be helpful. I don't know majordomo very intimately (neither do I want to get to know it all that much better :), so getting a second opinion would be wise :) Still, config_parse.pl says: # provide list of known keys. If value is '', then the key is undefined # I.e. the action is just as though there was no keyword found. # otherwise the value is the default value for the keyword. # if the value starts with #!, the rest of the value is eval'ed %known_keys = ( [...] 'precedence', 'bulk', # Set/install precendence header implying that "bulk" is the default value for the "precedence" configuration setting. -- Harald From neves@inf.puc-rio.br Mon Dec 21 23:27:08 1998 From: neves@inf.puc-rio.br (Paulo Eduardo Neves) Date: Mon, 21 Dec 1998 20:27:08 -0300 Subject: [Mailman-Developers] The bulk issue References: <13948.4007.271847.853690@anthem.cnri.reston.va.us> Message-ID: <367ED94C.C66FFD69@inf.puc-rio.br> "Barry A. Warsaw" wrote: > > >>>>> "HM" == Harald Meland writes: > > HM> I have no idea where, or even if, "Precedence: list" is > HM> standardized in any way, but I think that thath is what > HM> majordomo is inserting. Being compatible with majordomo when > HM> it doesn't cost us anything is also, IMHO, a good thing. > > As far as I can tell, it is not documented anywhere; not even in the > update to RFC 2076. I'll see if I can search around in Majordomo to > see what they do, but if anybody else can verify this, it would be > helpful. I've signed Listserv support list for sometime and this was a frequent question. The Precedence: list header isn't in any standard. If I remember well you will find info just in sendmail docs. It was invented by Eric Allman, who is the author of Sendmail mail and of the vacation program. Listserv refuses to add it since it isn't in the standards. > > HM> The only reason I see for _not_ adding any Precedence: header, > HM> is that Mailman-delivered messages have half a truckload of > HM> headers as it is. But that, IMHO, isn't really a strong > HM> argument -- as long as all the headers are there for some good > HM> reason, they _should_ be in there. > > Yeah, and the IETF draft adds 9 more headers ;-( I agree that there's no problem adding it, since it avoids problems to the list. []s -- Paulo Eduardo Neves PUC-Rio de Janeiro Pager: Central: 292-4499 cod. 213 99 64 ou use a URL: http://www.learn.fplf.org.br/neves/mensagempager.html From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Tue Dec 22 04:18:20 1998 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Mon, 21 Dec 1998 23:18:20 -0500 (EST) Subject: [Mailman-Developers] smtplib.py Message-ID: <13951.7564.907978.393759@anthem.cnri.reston.va.us> I think I've integrated the Python 1.5.2 smtplib.py into Mailman for 1.0b7. I'm no smtp expert so I'd like someone with CVS access to double check what I've done. Here's a summary. I am removing Mailman/smtplib.py, and creating a new package directory inside Mailman called Mailman/pythonlib. This package will contain newer versions of standard Python libraries, that may not exist (or be out of date) out in the field. E.g. this directory now contains smtplib.py from nearly-Python-1.5.2. If we ever have version skew down the road, this may contain other copies of such libraries. When require Python 1.5.2 or better, we can remove Mailman/pythonlib/smtplib.py Now, I've tracked down every reference to smtplib.py and the only useful one seems to be Mailman/Utils.py. I've removed all other imports of smtplib from places where they were not used. Then I modified TrySMTPDelivery() in Utils.py to get the correct smtplib (standard Python one if the attribute smptlib.SMTP.ehlo exists, otherwise, it imports the one out of the Mailman.pythonlib package). Finally, I rewrote the code in this function to call the standard interface, which seems very simple: essentially call smtplib.SMTP(...).sendmail(). In my limited testing, this appears to work just fine. I plan to check all this stuff in in a few moments. Please someone double check me. If I've messed up badly, I'll revert. Also, I plan to move bin/update_to_10b6 to bin/update. We'll just keep adding new update procedures to this script as new versions are released. I plan to add removal of $prefix/Mailman/smtplib.py{,c}. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Dec 23 00:12:47 1998 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Tue, 22 Dec 1998 19:12:47 -0500 (EST) Subject: [Mailman-Developers] The bulk issue References: <13948.4007.271847.853690@anthem.cnri.reston.va.us> <367ED94C.C66FFD69@inf.puc-rio.br> Message-ID: <13952.13695.962925.907350@anthem.cnri.reston.va.us> Okay, I have added "Precedence: bulk" headers to both normal deliveries and to the digest envelopes. While there's some disagreement among people, this definitely helps some folks, and shouldn't hurt everyone else. I am not adding other non-standard mailing list related headers, since that's *a lot* more headers for IETF draft support of a feature with marginal value. We could add these later easily. -Barry From sjp@buzzsaw.net Wed Dec 23 22:02:33 1998 From: sjp@buzzsaw.net (Steve Phillips) Date: Wed, 23 Dec 1998 16:02:33 -0600 (EST) Subject: [Mailman-Developers] Problems getting news/mail gateway working (with fixes) Message-ID: System: Debian: 2.0 Mailman: 1.0b6 (compiled, not from .deb package) Inn: 1.7.2 (debian package version 1.7.2-4) I found one bug in the Python source and one installation error: I'm trying to set up Mailman on my system to gateway between mail and news. I found I was getting the following error in my syslog when trying to gateway mail to news: ----------------------------------------------------------------------- Dec 23 13:05:00 hodag /USR/SBIN/CRON[12324]: (mailman) CMD (/usr/bin/python /hom e/m/mailman/cron/gate_news) Dec 23 13:09:05 hodag sendmail[12352]: NAA12352: from=, si ze=671, class=0, pri=30671, nrcpts=1, msgid=<36813FAF.710DD6C6@siliconlogic.com> , proto=ESMTP, relay=relay.siliconlogic.com [207.67.84.2] Dec 23 13:09:05 hodag sendmail[12353]: NAA12353: clone NAA12352, owner=test-admi n Dec 23 13:09:07 hodag nnrpd[12358]: hodag.buzzsaw.net connect Dec 23 13:09:07 hodag nnrpd[12358]: hodag.buzzsaw.net post failed Duplicate "Sen der" header Dec 23 13:09:07 hodag nnrpd[12358]: hodag.buzzsaw.net exit articles 0 groups 0 Dec 23 13:09:07 hodag nnrpd[12358]: hodag.buzzsaw.net posts received 0 rejected 1 Dec 23 13:09:07 hodag nnrpd[12358]: hodag.buzzsaw.net times user 0.010 system 0. 010 elapsed 0.131 ----------------------------------------------------------------------- Looks like it failed because the header that innd got was bad. Investigation revealed this bit of code from GatewayManager.py: subj = msg.getheader('subject') if not subj: msg.SetHeader('Subject', '%s(no subject)' % prefix) if self.reply_goes_to_list: del msg['reply-to'] msg.headers.append('Reply-To: %s\n' % self.GetListEmail()) msg.headers.append('Sender: %s\n' % self.GetAdminEmail()) msg.headers.append('Errors-To: %s\n' % self.GetAdminEmail()) msg.headers.append('X-BeenThere: %s\n' % self.GetListEmail()) msg.headers.append('Newsgroups: %s\n' % self.linked_newsgroup) Looks like a new Sender: line is getting added, but the original one is not removed. I commented out this line and then things started working. As for news to mail: I got the following error for that: ----------------------------------------------------------------------- Received: (from root@localhost) by hodag.buzzsaw.net (8.8.8/8.8.8/Debian/GNU) id PAA13832 for mailman; Wed, 23 Dec 1998 15:30:05 -0600 Date: Wed, 23 Dec 1998 15:30:05 -0600 Message-Id: <199812232130.PAA13832@hodag.buzzsaw.net> From: root (Cron Daemon) To: mailman Subject: Cron /usr/bin/python /home/m/mailman/cron/gate_news X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: sh: /home/m/mailman/scripts/post: Permission denied ----------------------------------------------------------------------- Installed permisions on "post" were: -rw-r--r-- 1 root mailman 2832 Dec 23 14:14 post I did chmod 755 on post and then things started working correctly. From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Dec 24 04:16:46 1998 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 23 Dec 1998 23:16:46 -0500 (EST) Subject: [Mailman-Developers] Problems getting news/mail gateway working (with fixes) References: Message-ID: <13953.49198.383176.471856@anthem.cnri.reston.va.us> Thanks Steve. Actually both this bugs have already been fixed for the next release. You can get the new GatewayManager.py file from the CVS tree (or if it's urgent I can send it to you). -Barry From Harald.Meland@usit.uio.no Wed Dec 30 18:52:55 1998 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 30 Dec 1998 19:52:55 +0100 Subject: [Mailman-Developers] configure not aware of Mailman/pythonlib In-Reply-To: "Barry A. Warsaw"'s message of "Mon, 21 Dec 1998 23:30:54 -0500 (EST)" References: <199812220430.XAA13534@anthem.cnri.reston.va.us> Message-ID: I just braved upgrading from beta 6 to the current CVS version, and got slightly bruised from the fact that configure doesn't know anything about the Mailman/pyhtonlib directory. I think the patch below fixes this (if you run "aclocal; autoconf" after applying it, of course), but then I'm not very familiar with autoconf, so I could be totally wrong :) Index: configure.in =================================================================== RCS file: /projects/cvsroot/mailman/configure.in,v retrieving revision 1.26 diff -u -r1.26 configure.in --- configure.in 1998/11/17 23:49:12 1.26 +++ configure.in 1998/12/30 18:46:51 @@ -364,7 +364,7 @@ AC_OUTPUT([misc/paths.py Mailman/Defaults.py Mailman/mm_cfg.py.dist src/Makefile misc/Makefile bin/Makefile Mailman/Makefile Mailman/Cgi/Makefile Mailman/Logging/Makefile - Mailman/Archiver/Makefile + Mailman/Archiver/Makefile Mailman/pythonlib/Makefile mail/Makefile templates/Makefile cron/Makefile filters/Makefile scripts/Makefile cron/crontab.in Makefile]) -- Harald From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Dec 30 19:08:24 1998 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 30 Dec 1998 14:08:24 -0500 (EST) Subject: [Mailman-Developers] configure not aware of Mailman/pythonlib References: <199812220430.XAA13534@anthem.cnri.reston.va.us> Message-ID: <13962.31272.690202.100002@anthem.cnri.reston.va.us> >>>>> "HM" == Harald Meland writes: HM> I just braved upgrading from beta 6 to the current CVS HM> version, and got slightly bruised from the fact that configure HM> doesn't know anything about the Mailman/pyhtonlib directory. HM> I think the patch below fixes this (if you run "aclocal; HM> autoconf" after applying it, of course), but then I'm not very HM> familiar with autoconf, so I could be totally wrong :) Something's wrong with the CVS mirror because that change should be in the source. It looks like the files didn't get mirrored to the external server... I'm not sure why! I've just done a manual sync, so please try again. I'll try to keep an eye on things to see if the rsync process is failing somehow. Thanks, -Barry From Harald.Meland@usit.uio.no Wed Dec 30 20:02:38 1998 From: Harald.Meland@usit.uio.no (Harald Meland) Date: 30 Dec 1998 21:02:38 +0100 Subject: [Mailman-Developers] configure not aware of Mailman/pythonlib In-Reply-To: "Barry A. Warsaw"'s message of "Wed, 30 Dec 1998 14:08:24 -0500 (EST)" References: <199812220430.XAA13534@anthem.cnri.reston.va.us> <13962.31272.690202.100002@anthem.cnri.reston.va.us> Message-ID: [Barry A. Warsaw] > I've just done a manual sync, so please try again. Done. Things sure look better now :) [ In the hope that it might help you debugging, here are the files that were changed by the update: Makefile.in UPGRADING configure configure.in bin/Makefile.in bin/update doc/LISA-98/README doc/LISA-98/published.ps mail/contact_transport ] -- Harald From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Dec 31 22:54:41 1998 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 31 Dec 1998 17:54:41 -0500 (EST) Subject: [Mailman-Developers] [ANNOUNCE] Mailman 1.0b7 Message-ID: <13964.177.459126.902326@anthem.cnri.reston.va.us> Folks, I've built the tarball for the Mailman 1.0b7 release, however since John appears to be not reading his email during the holiday season, the Web pages at www.list.org have not yet been updated. For now, you can grab the tarball from ftp://ftp.python.org/pub/tmp/mailman-1.0b7.tgz and we'll get the Web site updated ASAP. Below is an excerpt from the DONE file which gives some highlights for this release. My hope is that y'all will bang on this version in the next week or two and, if there are no showstoppers, we can get the full 1.0 release out by mid-January. Given the holiday season, a couple of weeks late isn't so bad! Let me also say that we've got a huge backlog of very good suggestions, contributions, ideas, etc. and on behalf of the other 3 core developers I thank you and encourage you to continue giving feedback. I've spent most of the last 10 days on vacation just trudging through 400-odd messages that I'd accumulated, and I think 1.0b7 fixes most of the really nasty bugs that have been reported up until now. What I haven't done is spend much time adding new features and I don't expect to until after 1.0 final is released. I firmly believe we need to get a stable 1.0 out RRSN, then we can begin to prioritize the new features for 1.1. High on my list is internationalization and an improved Web navigation interface. Longer term, I'm looking at Zope as a possible platform for Mailman. I know John, Ken, and Scott all have their priorities too. Big thanks go to those guys, and especially Scott Cotton, for their work on this release. Enjoy, and have a Happy New Year. -Barry -------------------- snip snip -------------------- 1.0b7 - Many, many bug fixes. Some performance improvements for large lists. Some improvements in the Web interfaces. Some security improvements. Improved compatibility with Python 1.5. - bin/convert_list and bin/populate_new_list have been replaced by bin/add_members. - Admins can now get notification on subscriptions and unsubscriptions. Post are now logged. - The username portion of email addresses are now case-preserved for delivery purposes. All other address comparisions are case-insensitive. - New default SMTP_MAX_RCPTS that limits the number of "RCPT TO" SMTP commands that can be given for a single message. Most MTAs have some hard limit. - "Precedence: bulk" header and "List-id:" header are now added to all outgoing messages. The latter is not added if the message already has a "List-id:" header. See RFC 2046 and draft-chandhok-listid-02 for details. - The standard (as of Python 1.5.2) smtplib.py is now used. - The install process now compiles all the .py files in the installation. - Versions of the Mailman papers given at IPC7 and LISA-98 are now included.