Mailman 3 May 2000 - Mailman-Developers

A request - increased clarity in <listname>-request responses
by Adrian Joseph May 8, 2000

May 8, 2000

Hi, I'm not a subscriber to this list, but I'm the admin for a number of mailing lists using Mailman v1.1. One thing which has proved to be a problem is the relative lack of clarity in the replies to mailcmd subscribe & unsubscribe attempts. Since it has become common for companies to tack on lengthy legal disclaimers, the resulting output from the parser, ending in " Too many errors encountered; the rest of the message is ignored:", is more than enough to confuse those who are not computer savvy· I know the relevant information is present in the mail, but I've had literally hundreds of e-mail from confused would-be subscribers to demonstrate that its presentation needs some improvement. Griping aside I think its a pretty cool app, thanks folks Adrian

2 1

1.1 bug: mailman home path scattered throughout config.db
by Dan Mick May 5, 2000

May 5, 2000

Argh. I just spent an hour trying to figure out why some lists that I'd moved from a machine with /home/mailman to a machine with /export/home/mailman would *not* archive. It's because there were (at least) three variables in config.db for each list that contain the base path, apparently persistently, so changing PREFIX in Defaults.py isn't enough: public_archive_file_dir private_archive_file_dir archive_directory If I don't have something else misconfigured which causes these to show up in config.db, I call this a bug.

2 1

Some refinements coming
by bwarsaw＠python.org May 4, 2000

May 4, 2000

Some time over the next few days I'm going to check in a bunch of related refinements which should make message delivery much more robust than it is in 2.0beta2. In brief, this expands on the mechanism that SMTPDirect.py used to queue up files for which there were delivery failures to some or all recipients. For example, here's a scenario that could cause messages under beta2 to get dropped, but which will be handled more gracefully in beta3. Say there's some long running process that is claiming a list lock, e.g. bin/withlist. A message arrives destined for the same list, but the lock lifetime is fairly long and scripts/post can't acquire the list lock. Maybe you're running Postfix and you hit command_time_limit, SIGKILLing post (ouch!). That incoming message is lost forever, and That's Bad (tm). What you can do now is set the list lock acquisition timeout to something shorter than command_time_limit. This would cause scripts/post to get a TimeoutError on list acquisition, which it can catch and use to the queue the message. cron/qrunner can then attempt redelivery the next time it runs. The new scheme will also mean that delivery failures generated by Sendmail.py will be queued just like for SMTPDirect.py. Also, if there any uncaught exceptions in a handler module, the message will be queued instead of being lost (with a traceback showing up in logs/errors so you can fix it and try attempt redelivery). One of the cool things is that a message knows how far in the pipeline it got, so when qrunner attempts redelivery, it'll pick up where it left off before, skipping modules that succeeded the first time. Note though that if you change the pipeline after the message has been queued, the message will not flow through the new pipeline. These changes touch many pieces of Mailman and I wish I didn't have to do this so deeply into the beta cycle, but I think it's really really important to make sure that messages never get lost. Currently, the API to delivery modules has changed (which also sucks for a beta release), but I think I'm going to fix that before beta3 goes out. This stuff is also only minimally tested, so don't go updating your production systems yet. I'm not sure I figured out all the nuances or entry points, but my simple tests work. I want to check it all in so there's a cvs record of the changes, many of which have been sitting in my devel directory for days. Also, it'll be nice to have more eyes look at this stuff. Stay tuned. -Barry

1 0

www.list.org is down?
by Chuq Von Rospach May 4, 2000

May 4, 2000

I'm unable to connect to www.list.org. Is it down? -- Chuq Von Rospach, Apple Mail List Gnome (mailto:chuq@apple.com) + (mailto:chuqui@plaidworks.com)

4 3

Re: [Mailman-Developers] change the envelope sender with Sendmail.py?
by Brian Edmonds May 4, 2000

May 4, 2000

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nigel Metheringham <Nigel.Metheringham(a)VData.co.uk> writes: >> I'm going to have to use Sendmail.py as the interface to my >> outgoing-only Postfix installation. > Wierd... why on earth not. Can't you have a localhost SMTP listener? I *do* have a localhost SMTP listener, and that's Sendmail, because I've been using Sendmail for years, and have a slightly complicated mail setup that will take a bit of time to convert to Postfix. > Look back in the archives for the thread "New MTA interface in mailman > 2.0b" around 10 April. Thanks, will do. Brian. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <http://www.gnupg.org/> iD8DBQE5EYdxcCEFQUX5+OwRAnjVAJ0XXcwxnr2+aSAX3GZd7nGP3veBkwCfayMf /h48XMbxQ1hwTMdUoDS29/0= =YDAN -----END PGP SIGNATURE-----

1 0

Re: [Mailman-Developers] change the envelope sender with Sendmail.py?
by Nigel Metheringham May 3, 2000

May 3, 2000

brian(a)gweep.bc.ca said: > That's well and good, but until I can make the time to convert my > whole MTA setup over to Postfix, I'm going to have to use Sendmail.py > as the interface to my outgoing-only Postfix installation. Sendmail > (via SMTPDirect.py) simply does not work at all well with Mailman > 2.0beta2. Wierd... why on earth not. Can't you have a localhost SMTP listener? > And so far it does seem to be working just fine. What sort of > problems would you expect me to be seeing? Look back in the archives for the thread "New MTA interface in mailman 2.0b" around 10 April. Nigel. -- [ - Opinions expressed are personal and may not be shared by VData - ] [ Nigel Metheringham Nigel.Metheringham(a)VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ]

1 0

Re: [Mailman-Developers] New LockFile.py
by Nigel Metheringham May 3, 2000

May 3, 2000

claw(a)cp.net said: > Aside: Tripwire, Aide, and other filesystem based attack sensors will > tend to have fits over this. Lockfiles being checked within filesystem attack tools will give the administrator an awful lot of rubbish to examine per day - general tripwire would be happy as long as the permissions were not silly (ie setuid), and it was informed that the file (all files in that directory/filesystem area) were transient data, Nigel. -- [ - Opinions expressed are personal and may not be shared by VData - ] [ Nigel Metheringham Nigel.Metheringham(a)VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ]

1 0

Re: [Mailman-Developers] change the envelope sender with Sendmail.py?
by Brian Edmonds May 3, 2000

May 3, 2000

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nigel Metheringham <Nigel.Metheringham(a)VData.co.uk> writes: > The Sendmail.py module has a number of other problems, and I would > strongly suggest that it not be used at present - the name is a > reference to the calling interface used rather than necessarily the > MTA. That's well and good, but until I can make the time to convert my whole MTA setup over to Postfix, I'm going to have to use Sendmail.py as the interface to my outgoing-only Postfix installation. Sendmail (via SMTPDirect.py) simply does not work at all well with Mailman 2.0beta2. And so far it does seem to be working just fine. What sort of problems would you expect me to be seeing? Brian. PS: To recap, I've been using Majordomo with bulk_mailer and Sendmail for my lists. Sendmail is still my MTA but I've installed Postfix in outgoing only mode for Mailman to use. I'll switch to Postfix for the whole enchilada eventually, but that will take some time to set up. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <http://www.gnupg.org/> iD8DBQE5D39DcCEFQUX5+OwRAnleAJ9GwAJSiUr1SkrSmRQZnnU4UStmawCgvPT1 Rtxlx0lyrnDpq/DZrZvOHu8= =P2FU -----END PGP SIGNATURE-----

1 0

Re: [Mailman-Developers] New LockFile.py
by Dan Mick May 2, 2000

May 2, 2000

> >>>>> "RJ" == Ron Jarrell <jarrell(a)vt.edu> writes: > > RJ> Unless the machine crashed, which is why you're fscking the > RJ> file system :-). > > True, true. Setting dates in the future seems like a really bad idea to me...

6 7

Re: [Mailman-Developers] lock lifetime
by Harald Meland May 2, 2000

May 2, 2000

[bwarsaw(a)cnri.reston.va.us] > Actually, I just remembered sys.exitfunc! I can set that up to > unlock a locked list automatically at interpreter exit. I don't > want it to implicitly save the list though -- you'll still have to > do that manually if you fiddle with it from the interpreter prompt. > > Note that this function doesn't run if the interpreter exits because > of a signal or os._exit() call. Regarding signals: Some time back, I occasionally received reports from my users that some list, while its web admin interface was being accessed, suddenly got unresponsive for a period of time that matched the lock lifetime pretty well. There were no entries/backtraces in logs/error, but I sometimes saw list lock files left lying around, and upon checking their contents found that their creating process was now gone. I suspect this is what happened: * Web browser connects to Mailman. * Web browser for some reason closes its side of the connection before Mailman has given any response. * When Mailman tries to print out its response, it receives a SIGPIPE. I tried fixing the problem with this patch: Index: driver =================================================================== RCS file: /projects/cvsroot/mailman/scripts/driver,v retrieving revision 1.19 diff -u -r1.19 driver --- driver 2000/04/06 19:30:38 1.19 +++ driver 2000/04/12 14:43:23 @@ -89,6 +89,13 @@ main() finally: sys.stderr = sys.__stderr__ + except IOError, e: + import errno + if e.errno == errno.EPIPE: + # Log something + logger.write("EPIPE caught, ARGV=%s\n" % sys.argv) + else: + raise except SystemExit: # this is a valid way for the function to exit pass (Well, something like that patch anyway... :) However, if my understanding of the problem is right, and this is the correct fix for it, I don't understand why the bare except: clause around the run_main() call in driver didn't kick in to produce a log entry... Does anyone have any insight on how to properly avoid SIGPIPEs in python? -- Harald

2 1