Mailman 3 January 1999 - Mailman-Developers

New to Mailman, Question on Platforms
by Mark Williamson 09 Jan '99

09 Jan '99

I've looked through the archives, but i couldn't find the answer to my question. I am not proficient at all on Linux/Unix systems, just a novice. The bulk of my experience has been on NT. That leads to my question: SInce Python has been ported to NT, can mailman run on this platform? Are there any FAQ's, docs or links that i can read on how to do this? Or is this undoable because of the need to compile some of the .C programs? Can the .C program's functionality be duplicated on NT or rewritten in Python? Regards, Mark Williamson

3 3

Re: [Mailman-Developers] New to Mailman, Question on Platforms
by Mark Williamson 09 Jan '99

09 Jan '99

i.e. not worth the effort :) hehehe, always knew i'd put this redhat disk to use -----Original Message----- From: John Viega <John(a)list.org> To: Barry A. Warsaw <bwarsaw(a)cnri.reston.va.us>; Mark Williamson <markw98(a)ibm.net> Cc: mailman-developers(a)python.org <mailman-developers(a)python.org> Date: Saturday, January 09, 1999 11:47 AM Subject: Re: [Mailman-Developers] New to Mailman, Question on Platforms >I mostly agree with Barry's answer, but for different reasons. You >can use the cygwin stuff to get fork(), etc... under windows. There >is no reasonable *free* mail transport for windows that I know of, but >you could always pass that off to another machine, with some hacking. >I don't know what web servers look like for windows. All in all, the >pieces are probably all there, but there would be a lot of work >involved in getting everything working. > >John > > >On Sat, Jan 09, 1999 at 02:10:04PM -0500, Barry A. Warsaw wrote: >> >> >>>>> "MW" == Mark Williamson <markw98(a)ibm.net> writes: >> >> At this point, I think it's mostly undoable because of our heavy >> reliance on a forking model. Win32 doesn't have fork(). >> >> We've talked about moving to a threaded long-running server model, or >> adopting Zope <www.zope.org> as a platform, and both of those (very >> future) developments would probably let us support NT. >> >> -Barry >> >> _______________________________________________ >> Mailman-Developers maillist - Mailman-Developers(a)python.org >> http://www.python.org/mailman/listinfo/mailman-developers >

1 0

Logo contest
by Barry A. Warsaw 09 Jan '99

09 Jan '99

I would like to have a Mailman logo, that would serve a function similar to Just van Rossum's excellent "Python Powered" logo. I am not much of a (visual :-) artist so if I had to do it, I'd probably hack around with Gimp's logo scripts for an hour or so and come up with something really cheezy. So I figured I'd open up a logo contents with y'all to tap the fast energies and talents of our community. See http://www.python.org/psa/Logo.html for the logos that Just came up with for Python. Here are my requirements: - The phrase should be "Delivered by Mailman" - We should have a large logo and a small logo, of approximately the sizes Just chose, but I'm not as concerned about animated versions. - I'm thinking that the background should be a simple caricature of an envelope, either of the obverse side (with a stamp in the upper left corner), or the reverse side, with flap lines. This is just a suggestion. - Colors and fonts are up to you, but readability is of utmost importance. - GIF is probably the best format. - You will have to GPL your logo, and be willing to assign it to the FSF (and probably have your employer do the same). Send your submissions to me -- MIME is fine. I'll post them on the Web so we can all see and vote on them. The winner gets his or her little chunk of net.immortality and the eternal thanks of Mailman users for years to come. I would like to have a logo for the 1.0 release, which I think will realistically be end-of-January. Thanks, -Barry

1 0

shipstopper bug
by Greg Stein 09 Jan '99

09 Jan '99

I've reported this before, and I will reiterate it again. Moreover, I would call it a "shipstopper" for the 1.0 release. I'm using 1.0b6 here. This has hit me FIVE times in the past 24 hours. Each time, I have to take manual action to fix things (as reported before). Basically, shutting down the sendmail listener to stop the mail loop, clearing the Mailman queue and sendmail queue of the loop-inducing garbage, and then bringing it back up. What happens is that somebody types in a request to the Mailman subscription page with a *local* mail address (i.e. no domain name). The confirmation email then gets sent. This bounces back to Mailman, but it doesn't understand that it is a bounce and tries to process the dumb thing. That fails massively (as seen in the attached mail), and responds to mailer-daemon with the error. More on this in a bit. What appears wonky is that Mailman seems to attempt to deliver the confirmation over and over, nonstop. Here is a portion of the mail log for RAB25492: Jan 8 17:18:19 ns1 sendmail[25492]: RAA25492: <ch9517>... User unknown Jan 8 17:18:19 ns1 sendmail[25492]: lost input channel from localhost [127.0.0.1] Jan 8 17:18:19 ns1 sendmail[25492]: RAA25492: from=<hognews-request(a)eastsideharley.com>, size=0, class=0, pri=0, nrcpts=0, proto=SMTP, relay=localhost [127.0.0.1] Jan 8 17:18:19 ns1 sendmail[25492]: RAA25492: RAB25492: DSN: <ch9517>... User unknown Jan 8 17:18:27 ns1 sendmail[25492]: RAB25492: to=|"/home/mailman/install/mail/wrapper mailcmd hognews", delay=00:00:08, xdelay=00:00:07, mailer=prog, stat=Sent Note the "lost input channel". I don't think that is right. The cycle above repeats at 17:18:32. This goes on until I kill it. In the above case, the mailer-deamon is responding to Mailman (the last line). Mailman then processes that mail, and returns a message like the attached garbage to root. I just deleted 1400 messages from my root mailbox. Some more information: In logs/error, I see the following traceback repeated every 30 minutes: Jan 08 11:12:07 1999 smtplib: Traceback (innermost last): smtplib: File "/home/mailman/install/cron/run_queue", line 31, in ? smtplib: OutgoingQueue.processQueue() smtplib: File "/home/mailman/install/Mailman/OutgoingQueue.py", line 38, in processQueue smtplib: Utils.TrySMTPDelivery(recip,sender,text,full_fname) smtplib: File "/home/mailman/install/Mailman/Utils.py", line 201, in TrySMTPDelivery smtplib: con.send(to=recipient,frm=sender,text=text) smtplib: File "/home/mailman/install/Mailman/smtplib.py", line 75, in send smtplib: self.getresp() smtplib: File "/home/mailman/install/Mailman/smtplib.py", line 147, in getresp smtplib: raise bad, resp smtplib: smtplib.error_proto : 550 <bzkeffer>... User unknown I suspect that the "lost input channel" further above is due to a similar condition. The traceback drops the socket, fails to log anything, and fails to clear the confirmation email from the outgoing queue. Mailman processes the error response from mailer-daemon and drops it into the queue. It runs the queue which processes that response (flooding the root email box) along with the confirmation (again), which starts the loop again. I also believe that I now understand why my machine died back in August due to this bug, but that hasn't happened to me recently. Because of the queueing nature of Mailman, there is only one loop occurring at a time. HOWEVER: if that cron job wakes up and processes the queue, then it starts a second, simultaneous loop. If enough of those 30-minute cron-caused loop-creations occurs, then your machine is completely dead as it thrashes, trying to process all those loops. I've been catching them relatively soon in this past spate of them (although I did miss one last night for a long while, causing my loadavg to hit 15... heh. it's also a DNS server and its response became SLOWWWWWW... which led me to look into it) So, I see one or more errors here: 1) a possible traceback not being logged during Q processing 2) said traceback fouling the outgoing mail queue processing 3) should probably disallow domain-less addresses in all places 4) bounce detection needs to recognize the mail that caused the attached response (read between the lines for the content) And because this can swamp a box, I would highly recommend it gets fixed :-) thx -g -- Greg Stein, http://www.lyra.org/

2 1

is restricted unsubscribe possible?
by Peter Gervai 09 Jan '99

09 Jan '99

I think I failed to see how can I make a list set up so that its members cannot unsubscribe without owner's approval? (Or does "approval for subscribe" setting cover unsub messages as well?) I would like to use a list as our 'problem notification' service but I don't want to see clueless idiots, erm, I mean, windows users :) playing with subscriptions at all. It should be act just like a 'glorified alias file' (but much easier to handle). bye, grin

2 1

Mailman 1.0b7 bug reports
by Detlev Droege 09 Jan '99

09 Jan '99

Hi Mailman Developers, thanks for Mailman - its great to have that tool ! We did set up Mailman at http://mailhost.uni-koblenz.de/mailman/admin/ mostly to admin local user groups. I'm the list-admin of the single non-local group (EINST-Mitglieder). Most things run just fine, however I had following problems: 1 - I did a bulk subscribe for approx. 100 members via the HTML interface. I overlooked a bogus line when pasting the addresses into the textfield and Mailman generated a strange entry. A syntax check on the mail addresses would be helpful. [The bogus address had a pending closing paranthesis: "AUser(a)somewhere.com)" ] 2 - The abovementioned list of email addresses did contain mixed-case entries like "Detlev.Droege(a)uni-koblenz.de". Mailman did lowercase them in most places, but not in all places. The subscription welcome message to those members contained URLs like http://host/mailman/options/einst-mitglieder/Detlev.Droege@uni-koblenz.de to access the specific member record (note the upper case letters). The "options" program does not recognize these entries unles all letters are changed to lower case. Either the case in the generated mail should be changed or, even better, "options" should accept valid mail addresses in any case. 3 - When the first external member submitted an article, its From: address differed from the subscribed address, so I as the list admin was asked to approve the message. I did so, however the message was never sent out to the list members. It appears in the "post" logfile, it is archived in the HTML archive, but it was never mailed to the list members. Our postmaster could not detect any failure of our mail system nor any error messages. Is it possible Mailman just forgot to send it out ? 4 - As list admin I'd like to have an interface to change the mail address of list members. I allready got several requests to do so. It's a little boring to do so by unsubscribing the old and then subscribing the new address. Moreover, this generates a useles "Good Bye" and "Welcome" message which might confuse the subscriber. Anyway - Mailman is a great tool and I like it a lot ! Don't take this as complaint, but as my (very) small effort to make it even better. Detlev --- Detlev Droege, Uni Koblenz, FB Informatik, Rheinau 1, D-56075 Koblenz, Germany Fon: +49 261 287-2769 (NEU !) | Email: droege@informatik Fax: +49 261 287-2745 (NEU !) | .uni-koblenz.de

2 1

Re: [Mailman-Developers] fwd: Cron <mailman@myhost> /usr/bin/python /home/mailman/cron/senddigests (fwd)
by Harald Meland 08 Jan '99

08 Jan '99

[Jerry Adlersfluegel] > 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 290, in SendDigest > self.DeliverToList(d.Present(mime=0), > File "/home/mailman/Mailman/Deliverer.py", line 172, in DeliverToList > status = cmdproc.close() > IOError: (10, 'No child processes') > > > Any ideas? Yup. I believe this is a known problem with at least some RedHat cron daemons -- they run their jobs with some (rather vital, like SIGCHLD) signals set up to be ignored. Workaround: I think that adding something like this to the top of any script that is to be run from cron would work (as long as it is SIGCHLD that is being incorrectly ignored, anyway): import signal signal.signal(signal.SIGCHLD, signal.SIG_DFL) If this workaround does the job, it would IMHO be less obtrusive than the workaround currently in CVS. -- Harald

2 1

Little bug(?) in admindb
by Balazs Nagy 08 Jan '99

08 Jan '99

Hiyas, I got four pendings to an email list, but when I wanted to submit my changes, it said that there's an error in line #196. This is a for loop with form.keys() as k, but it cannot interpret form[k].value. I have no time because I want to finish my cgi extension and MTU patches but for the short-time fix I got out ValueError from the next except line. -- Linux Supporting Center -- Red Hat Qmail packages -- http://lsc.kva.hu PGP 0x1DE3631D / A8 B4 92 EE 1F 55 27 C8 86 64 9C 42 41 A4 BD B8 Don't spell GLIB backwards!

2 3

Admindb bug
by Balazs Nagy 08 Jan '99

08 Jan '99

Hiyas, There's an error in admindb in the login form. Here's the fast patch against the latest CVS snapshots: --- admindb.py.orig Fri Jan 8 18:23:22 1999 +++ admindb.py Fri Jan 8 18:23:44 1999 @@ -113,7 +113,7 @@ 'admlogin.txt', {'listname': list_name, 'path' : os.environ.get('REQUEST_URI', - '/mailman/admin/' + list_name), + '/mailman/admindb/' + list_name), 'message' : message, }) print text ... and of course against my patches: --- admindb.py.orig Fri Jan 8 18:20:15 1999 +++ admindb.py Fri Jan 8 17:45:02 1999 @@ -113,7 +113,7 @@ 'admlogin.txt', {'listname': list_name, 'path' : os.environ.get('REQUEST_URI', - '/mailman/' + mm_cfg.admin_cgi + '/' + list_name), + '/mailman/' + mm_cfg.admindb_cgi + '/' + list_name), 'message' : message, }) print text Regards: Jul -- Linux Supporting Center -- Red Hat Qmail packages -- http://lsc.kva.hu PGP 0x1DE3631D / A8 B4 92 EE 1F 55 27 C8 86 64 9C 42 41 A4 BD B8 Don't spell GLIB backwards!

1 0

My patches
by Balazs Nagy 08 Jan '99

08 Jan '99

Hiyas, Here are my patches. These do the following: 1-cmdhandler: simplification in `set' command 2-cgiext: adds CGI extension support (eg. admin -> admin.cgi) 3-mtu: replaces direct SMTP delivery with sendmail/qmail/smail etc software. -- Linux Supporting Center -- Red Hat Qmail packages -- http://lsc.kva.hu PGP 0x1DE3631D / A8 B4 92 EE 1F 55 27 C8 86 64 9C 42 41 A4 BD B8 Don't spell GLIB backwards!

1 0