Mailman 3 April 2002 - Mailman-Developers

year out of range in arch runner?
by Ron Jarrell 08 Apr '02

08 Apr '02

Well, this was fascinating... I unshunted a couple of hundred messages that were there because of the bounce runner problem. Didn't get the previous error, but got *1* of these: Apr 08 17:59:32 2002 (17641) Uncaught runner exception: year out of range Apr 08 17:59:32 2002 (17641) Traceback (most recent call last): File "/home/mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/home/mailman/Mailman/Queue/Runner.py", line 155, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman/Mailman/Queue/ArchRunner.py", line 54, in _dispose elif abs(now - mktime_tz(tup)) > \ File "/usr/local/lib/python2.2/rfc822.py", line 955, in mktime_tz t = time.mktime(data[:8] + (0,)) ValueError: year out of range Turns out it's one of my users who's using an old unix mail client that's not Y2K compatible... So his mail is arriving in the year 102. Date: Thu, 4 Apr 102 19:36:28 -0500 (EST)

1 0

2.1b1 new bug
by Ron Jarrell 08 Apr '02

08 Apr '02

I'm starting to get these periodically: Apr 08 06:33:16 2002 (527) Uncaught runner exception: local variable 'addr' refe renced before assignment Apr 08 06:33:16 2002 (527) Traceback (most recent call last): File "/home/mailman/Mailman/Queue/Runner.py", line 105, in __oneloop self.__onefile(msg, msgdata) File "/home/mailman/Mailman/Queue/Runner.py", line 155, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman/Mailman/Queue/BounceRunner.py", line 95, in _dispose if xlist.isMember(addr): UnboundLocalError: local variable 'addr' referenced before assignment I'm not quite current on cvs (haven't updated in a week) but none of the recent checkins looked like they'd cover this.

2 2

Yet another weird-a$$ potential attack problem...
by Chuq Von Rospach 08 Apr '02

08 Apr '02

Oh, man. This is my week for weird stuff. I've just finished tracking down and nuking a subscriber with a really noxious mailbot. The situation was that anyone posting to one of my lists would get a reply back from <major new york financial company name deleted> acknowledging the email. Needless, this was rather irritating to people. I finally had to address probe the entire list, because the mailbot was coming back from a domain that wasn't subscribed to the list (of course), and the mailbot successfully removed every piece of identifying information from the email except the subject line. It finally turned out to be a person's alumni email address (why are these things always problems?) at <major east coast engineering school university that should turn out people who know better delete> forwarding to his account at <yada yada etc>. I deleted it, banned the address, and sent him mail announcing him as the winner of the "you're the stupid mailbot winner!" message explaining why he was a dead man. (he responded this morning. It started with "why didn't you contact me?" and went downhill from there....) But another list user brought up an interesting point, and I want to throw it out here to see if it's a problem we should worry about. Since the mailbot responds to the given address with the subject line more or less intact, it seems to me like we have a hole in the mail-back validation system in this specific situation. Imagine this scenario: - I get mad at <company.com>. - I notice they have a braindead mailbot saying "thank you for e-mailing <company.com>. We want you to know we got your message regarding 'foo'". - I decide to mailbomb <company.com> - I forge a bunch of subscribe requests to a lists on a mailman server, all coming from <address(a)company.com>, asking to subscribe. I start with root, abuse, ftp, admin, ceo, all -- have fun, it's cheap and easy. - All of these go to mailman, which sends back the confirmation message with the confirmation token in it. - this mailbot gets a copy and sends back it's "thanks for mailing us..." -- and includes the subject line, which includes the token. - which, AFAIKT, confirms the subscription, making the attack successful. Now you have a bunch of folks who got the confirmation message out of nowhere, but the confirmation message says to reply or nothing will happen. They odn't reply, but they'll find themselves subscribed anyway, because the mailbot confirmed the subscription FOR them. And now they're pissed at us, the list server owners. Now, part of me wants to respond "your own damn fault for running such a braindead mailbot in such a stupid way", but at the same time, I don't think mailman should allow for attacks even if it requires braindeadness on the part of the IS people on the other domain (in this case, I'm not sure the IS people are to blame, I think it's the corporate lawyers). The question I'm bringing up is, I guess, is this something mailman needs to worry about? Should it require that the returned token come from the address being subscribed? (or does it already? In this case, it came from a generic mailbot address @ that domain. An address which, fwiw, bounces if you mail to it. Grimace.). I realize that the "reply to confirm" is easy for users, but does it leave us open to abuse in other ways? Should we make some cahnge to the process that requires a person to do something? I don't have a good answer for any of this. I'm not even sure we should consider it a problem. But since I've identified it as a possible security flaw, I want to throw it out and let everyone chew on it. What do folks think about this? I'm worried about setting up mailman to allow for attacks on people or sites, even if it's a limited set of sites set up a specific way (shades of ORBZ and the Lotus Notes domino bug...). On the other hand, IS it their fault for building a stupid tool? Or is that no excuse to not protect ourselves from stupidity? -- Chuq Von Rospach, Architech chuqui(a)plaidworks.com -- http://www.chuqui.com/ No! No! Dead girl, OFF the table! -- Shrek

10 18

Apache 2.0.x
by Luigi Rosa 08 Apr '02

08 Apr '02

Are there any problems or caveat relating to Mailman about upgrading Apache to V2.0? Thanks. Ciao, luigi

1 0

Re: [Mailman-Developers] [PATCH] Fix endless prefix adding with q-p/base64 Subject lines
by Mikhail Zabaluev 08 Apr '02

08 Apr '02

Hello Ben, On Mon, Apr 08, 2002 at 06:10:20PM +0900, Ben Gertzfield wrote: > > On Monday, April 8, 2002, at 05:42 , Mikhail Zabaluev wrote: > > >Finally it's getting fixed. Still though, there is a possibility of > >the prefix being scattered between encoded/ASCII chunks; this code > >will not find it then. I haven't seen yet if this case is realistic or > >not. > > We might be able to fix this by making email.Header.decode_header() take > an optional flag to merge un-encoded (us-ascii) header chunks with the > next adjacent chunk, since we assume that all charsets have us-ascii as > a strict subset. Broad assumptions stink :) Why not Unicode, however? It would be nice if email.Header.Header objects would dump themselves into Unicode strings, so that we can match regex there without hassle. See my feature request at SF for mimelib. > I do not think this case is particularly realistic, though. I've > certainly never seen any mailer that would split in the middle of the > prefix and encode half of it, but who knows. Indeed. And anyone can set prefixes with spaces, mixed languages and so on. -- Stay tuned, MhZ JID: mookid(a)jabber.org ___________ Fun Facts, #14: In table tennis, whoever gets 21 points first wins. That's how it once was in baseball -- whoever got 21 runs first won.

2 2

iso_xxx subjects not processed?
by Fil 08 Apr '02

08 Apr '02

Hello, we had discussed a while ago of mailman decoding the iso_xxx subject lines in order not to add x times the subject_prefix ; I don't remember if there was a patch and if it was to be included in the official Mailman. Anyone knows? (In any case, it's not working on my installation, done from cvs one or twoo weeks ago). -- Fil

5 9

Re: [Mailman-Developers] qrunner still broken
by barry＠zope.com 07 Apr '02

07 Apr '02

>>>>> "BD" == Brett Delmage <brett(a)twobikes.ottawa.on.ca> writes: BD> In case anyone is interested, my problem was that BD> /usr/lib/python2.1/lib-dynload/_weakref.so BD> was missing. weakref.py[c] was present in the parent lib BD> drectory. Nasty. | This was a problem on SusE 7.3 with Python 2.1.1 | (#1, Sep 24 2001, 05:28:47). BD> Does anyone know if this file is not part of python 2.1.1 or BD> did SusE miss something? I verified the python rpm and nothing BD> was missing off the disk. BD> Should the minimum, as opposed to recommended, requirements BD> for mailman be changed to 2.1.2+ ? That file definitely gets build and installed when you use the Python source distro. Maybe the SuSE distribution is broken? Try building Python from source (it's easy!) and see if that fixes your problem. You're experience wasn't for naught though. I think the log message should have included the exception that occurred, and I've fixed qrunner to do that. -Barry

1 0

Re: [Mailman-Developers] qrunner still broken
by Brett Delmage 07 Apr '02

07 Apr '02

In case anyone is interested, my problem was that /usr/lib/python2.1/lib-dynload/_weakref.so was missing. weakref.py[c] was present in the parent lib drectory. This was a problem on SusE 7.3 with Python 2.1.1 (#1, Sep 24 2001, 05:28:47). Does anyone know if this file is not part of python 2.1.1 or did SusE miss something? I verified the python rpm and nothing was missing off the disk. Should the minimum, as opposed to recommended, requirements for mailman be changed to 2.1.2+ ? cheers, Brett On Sun, 7 Apr 2002, Brett Delmage wrote: > I'm still getting the same errors as below, with the latest CVS (as of > today) and a clean build/compile/install. > > I would sure appreciate any hints -- even the right questions to get me > checking the right things. > > > On Mon, 18 Mar 2002, Brett Delmage wrote: > > > I updated from 2.1a4 to 2.1b1 this weekend. SuSE 7.3, python 2.1.1 > > > > A problem showed up during make install, where paths.py was not copied > > into the bin, scripts, cron directories. I copied it in manually and that > > cleared the initial problems: the Cgi parts seemed to work (without > > exhaustive testing). > > > > Now I'm running into the followuing problems with qrunner but I am not > > sure where to look. Suggestions? It looks like it might still be related > > to paths.py? > > > > Brett > > > > > > > > # bin/mailmanctl start > > Starting Mailman's master qrunner. > > Cannot import runner module Mailman.Queue.VirginRunner > > Cannot import runner module Mailman.Queue.CommandRunner > > Cannot import runner module Mailman.Queue.IncomingRunner > > Cannot import runner module Mailman.Queue.ArchRunner > > Cannot import runner module Mailman.Queue.BounceRunner > > Cannot import runner module Mailman.Queue.NewsRunner > > Cannot import runner module Mailman.Queue.OutgoingRunner > > > > > > in logs/error: > > > > Mar 18 00:41:58 2002 mailmanctl(4463): > > Mar 18 00:42:06 2002 qrunner(4472): Cannot import runner module Mailman.Queue.VirginRunner > > Mar 18 00:42:06 2002 qrunner(4468): Cannot import runner module Mailman.Queue.CommandRunner > > Mar 18 00:42:06 2002 qrunner(4469): Cannot import runner module Mailman.Queue.IncomingRunner > > Mar 18 00:42:07 2002 qrunner(4466): Cannot import runner module Mailman.Queue.ArchRunner > > Mar 18 00:42:08 2002 qrunner(4467): Cannot import runner module Mailman.Queue.BounceRunner > > Mar 18 00:42:08 2002 qrunner(4470): Cannot import runner module Mailman.Queue.NewsRunner > > Mar 18 00:42:08 2002 qrunner(4471): Cannot import runner module Mailman.Queue.OutgoingRunner > > > > in logs/qrunner: > > > > Mar 18 00:42:06 2002 (4465) Master qrunner detected subprocess exit > > (pid: 4472, sig: 0, sts: 15, class: VirginRunner, slice: 1/1) > > Mar 18 00:42:06 2002 (4465) Master qrunner detected subprocess exit > > (pid: 4468, sig: 0, sts: 15, class: CommandRunner, slice: 1/1) > > Mar 18 00:42:06 2002 (4465) Master qrunner detected subprocess exit > > (pid: 4469, sig: 0, sts: 15, class: IncomingRunner, slice: 1/1) > > Mar 18 00:42:07 2002 (4465) Master qrunner detected subprocess exit > > (pid: 4466, sig: 0, sts: 15, class: ArchRunner, slice: 1/1) > > Mar 18 00:42:08 2002 (4465) Master qrunner detected subprocess exit > > (pid: 4467, sig: 0, sts: 15, class: BounceRunner, slice: 1/1) > > Mar 18 00:42:08 2002 (4465) Master qrunner detected subprocess exit > > (pid: 4470, sig: 0, sts: 15, class: NewsRunner, slice: 1/1) > > Mar 18 00:42:08 2002 (4465) Master qrunner detected subprocess exit > > (pid: 4471, sig: 0, sts: 15, class: OutgoingRunner, slice: 1/1) > > > > > > > > _______________________________________________ > > Mailman-Developers mailing list > > Mailman-Developers(a)python.org > > http://mail.python.org/mailman/listinfo/mailman-developers > > > > > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers(a)python.org > http://mail.python.org/mailman/listinfo/mailman-developers >

1 0

SF bug report #223533
by barry＠zope.com 07 Apr '02

07 Apr '02

I'm in a mad quest to reduce the number of open Mailman bugs to under 50 so it fits on one page. I'm nearly there. I'd like to get some feedback on bug #223533: http://sourceforge.net/tracker/index.php?func=detail&aid=223533&group_id=10… It's fairly old <blush> but it's complaining that there is no way to tell the difference between a list posting and an administrative message via the List-* headers. I think it's actually recommending to add another header(!) only to list postings. I'm basing my opinion on RFCs 2919 and 2369: http://www.faqs.org/rfcs/rfc2919.html http://www.faqs.org/rfcs/rfc2369.html The former outlines the List-ID: header and the latter outlines all the other List-* headers. Both of them describe when to add the headers to an outgoing message: [language taken from RFC 2369, but 2919 is the same -BAW] 3. The List Header Fields This document presents header fields which will provide the command syntax description for the 'core' and key secondary functions of most email distribution lists. The fields implemented on a given list SHOULD be included on all messages distributed by the list (including command responses to individual users), and on other messages where the message clearly applies to one distinct list. There MUST be no more than one of each field present in any given message. These fields MUST only be generated by mailing lists, not end users. My interpretation of this paragraph says that Mailman is doing the right thing by adding all those headers to all outgoing messages. The complaint is that you can't reliably set up something like a procmail filter to distinguish between admin messages and postings, but I think we're being standards compliant here and I'm inclined to close this bug report as Won't Fix. I'm open to other opinions. -Barry

6 13

pipermail replacement
by Eric Hanson 07 Apr '02

07 Apr '02

First post. Hello all. There have been several mentions of the need for a mailing list with a web interface, something that allows mailing list functionality and a web interface that allows posting, user accounts, threading etc. I've been thinking about such a thing using the XML server 4suite server (4suite.org) and mailman, essentially replacing pipermail. Here's my question. What about abandoning mbox format and storing emails in the XML repository? Are there a lot of mbox specific things in Mailman? Is this a sane thing to do? Regards, Eric

2 1