Mailman-Developers October 2000

mailman-developers@python.org

36 participants
55 discussions

Re: [Mailman-Developers] Re: Security
by J C Lawrence 25 Oct '00

25 Oct '00

On Tue, 24 Oct 2000 09:38:56 +0200 (CEST) Dan Ohnesorg <dan(a)feld.cvut.cz> wrote: > On Mon, 23 Oct 2000, J C Lawrence wrote: >> I'm certain the bug is not in Apache as it also occurs on post >> passing straight to the list without going thru moderation. It >> is possible it is in Exim, tho I'd be extremely surprised. For >> one I've reinstalled all binaries from known good sources, and >> have MD5ed all Exim files against both known good sources and the >> copies installed on other happily running machines. It is also >> unlikely that the bug is in the kernel as I've reproduced the >> problem with kernels built on other (untouched) machines and then >> installed on the offending machine, and on kernels built locally >> from cryptographically verified source balls. > I am running mailman from the beginning of mailman developing > (John Viegas version, Im not sure if the name is correct, but > cheers John). As have I. > It runs on SMP machine and I have never such a problem. Ditto. I currently have various versions of Mailman running on three SMP systems without problems. The fact that this particular (other) SMP system is having Mailman problems does not seem related to SMP. > I have seen problems with forking of sendmail into 1000 processes > while delivering messages in big (500 members) lists after > comminting pending request. This is a common MTA configuration issue, most often seen with QMail FWLIW. MTA tuning, especially as mail volumes grow, is a bit of an art. There was some interesting discussion on this area between Me and Chug on this list a couple months back you might want to look at. > But my kernel was never confused from this like Yours. I would > say, Your memory chips are wrong. User space program can never > corupt filesystem. It is possible I have bad RAM. It seems rather unlikely however (see below), You are missing data from the beginning of the thread. I had a disk die (it held various mail archives). In dieing it not only took down the system, but also succeeded in trashing various bits of other filesystems on other devices. Among the files trashed were the tripwire database and its backups. This was not apparent when I replaced the drive and restored all relevant files from known-good/secure backups. Given the new drive, the system remained unstable, crashing frequently (uptime measured in single digit hours). This is as compared to a previous uptime of near 200 days. I then replaced every binary on the system from original verified packages, encluding the kernel (built a new kernel locally from cryptographicslly signed and checked sources, using a new hand-checked .config). Crashes continued and seemed to be coincident with mail travelling thru Mailman, either thru the weba approval process, or direct through to the exploder (no approval) The MTA at this point appeared to be happy. Several tens of thousands of messages a day travel through that system, and were successfully passing through the system between crashes (my secondary MXes were dumping mail onto the system at a rate of well over 2K messages per minute upon rebooting from an extended crash -- which the system took quite happily). All crashes were observed to be time coincident with Mailman mail activities. Suspecting bad disk blocks and potentially other hidden filesystem troubles I then replaced all filesystems (except / and /boot) on the system with journalling filesystems (ReiserFS), doing a surface check on all partitions before putting the new filesystems on. I again replaced every binary on the system from confirmed correct packages, and built a new kernel on a known secure machine from crypographically signed and checked sources. Additionally I double checked by doing MD5Sum signature comparisons of key binaries on the target system, with specific attention paid the the mail system, against a known secure system. They matched perfectly. Finally I ran a semi-burn-in on the system: leaving it over night continuously building kernels AND using SCP to send those kernels to and from a remote box (to hit the network stack) with MD5 checks on each end AND sending an average of 25K mail messages per minute to a another system on the local net (100base-T connected). The next morning there was not a single error in any file, all SCP copies had compleated without error, all MD5 checks were passed, and neither MTA listed any problems (the messages themselves were bit-bucketted). I then rolled the box back into production. Crashes continued. They also continued after building a new kernel on the target machine -- from similarly verified sources (needed a slight tweak). I then replaced mailman from known good sources. Crashes continued. I've now removed all bytecoded files in the Mailman installation. Additionally I've hand unrolled and re-rolled the config.db for one of the lists that appears to be creating troubles. The unrolled DB looked good. Additionally, as I had in excess of 30K messages in my MTA spool pending delivery to assorted unresponsive remote systems and I suspected that a corrupted queue file might have been causing problems with Exim (which does briefly run as a privileged user), I hand moved all spool entries from the target system to another known-stable/secure system. We'll see what happens now. -- J C Lawrence Home: claw(a)kanga.nu ---------(*) Other: coder(a)kanga.nu http://www.kanga.nu/~claw/ Keys etc: finger claw(a)kanga.nu --=| A man is as sane as he is dangerous to his environment |=--

1 0

Security
by J C Lawrence 24 Oct '00

24 Oct '00

Barry, A week or so ago (right about the time I dissappeared) I had a drive die on the system I run Mailman from. I thought replacing the drive and restoring its contents from backups would be enough. It wasn't. It turns out that in dieing several other filesystems were corrupted in various odd and inelegant fashions (encluding both my tripwire DB and its backup sod it). This has left me in an odd position: If I post to a specific list, or approve a held post for that list, there is an 80% chance that this will crash the machine (compleat lock, no interrupts, no useful log entries. This is reproducable. I've done it a great many times -- enough to wish I had a watchdog card in that machine. Its also rather scary -- Mailman is running as a non-privileged user after all. As part of the recovery I've re-installed every single binary on the entire system (encluding Python et al). The one thing I haven't reinstalled is Mailman (v1.1). I also haven't dissembled or rebuilt the config.db's for the crashing lists. Interested in the relevant files? I'll be saving everything off (of course), but I doubt I'll have time in the near future to disect this. -- J C Lawrence Home: claw(a)kanga.nu ---------(*) Other: coder(a)kanga.nu http://www.kanga.nu/~claw/ Keys etc: finger claw(a)kanga.nu --=| A man is as sane as he is dangerous to his environment |=--

4 7

Re: [Mailman-Developers] Re: Security
by J C Lawrence 23 Oct '00

23 Oct '00

On Mon, 23 Oct 2000 20:44:45 -0700 Chuq Von Rospach <chuqui(a)plaidworks.com> wrote: > I sincerely doubt Barry would see it, because I'd be willing to > bet dinner it's a bad block on the disk, and it's lodged in one of > the files (probably the .db file) attached to that list. This was one of my early thoughts as well, but the fact that the behaviour continues after I've the partitions on the system and reformatted them with new filesystems (ReiserFS as versus Ext2FS) rather suggests this isn't it. > i'd do a surface test of that disk and see if it finds > problems. I'd give it 90% chance it will. This just screams "bad > block!" at me. <nod> That, and the frequent crash rate was one of the things that prompted me to put ReiserFS on. Before I'd figured that quite a bit had been messed up by the dieing drive I'd been seeing signs that several filesystems were unhealthy at the filesystem level. So I did surface checks, restored all the files, got crashes, did new surface checks and went to a new filesystem, rolled everything back and go crashes... -- J C Lawrence Home: claw(a)kanga.nu ---------(*) Other: coder(a)kanga.nu http://www.kanga.nu/~claw/ Keys etc: finger claw(a)kanga.nu --=| A man is as sane as he is dangerous to his environment |=--

1 0

Re: [Mailman-Developers] Security
by J C Lawrence 23 Oct '00

23 Oct '00

On Mon, 23 Oct 2000 20:09:01 -0700 (PDT) Dan Mick <Dan.Mick(a)West.Sun.COM> wrote: >> If I post to a specific list, or approve a held post for that >> list, there is an 80% chance that this will crash the machine >> (compleat lock, no interrupts, no useful log entries). > What do you mean "crash the system"? Panic and coredump? Hang? > Crash mailman/python and everything else is still up? As stated: compleat lock, no interrupts being serviced, no log entries. Basically: utterly indistinguishable from a powered off machine other than by power consumption. No KB, no met, no stack, no video (well, a slight grayish diffuse glow actually), nuttin'. > If panic/coredump, some time spent in cursory kernel coredump > analysis is warranted to point a finger at a culprit. Being a > kernel developer, I'm biased, but when people say "crash the > machine" that's what I think of. Is that what you mean? Nope. No panics, no cores, just one big wedgie. These are among the reasons this whole thing fits the description of "odd". -- J C Lawrence Home: claw(a)kanga.nu ---------(*) Other: coder(a)kanga.nu http://www.kanga.nu/~claw/ Keys etc: finger claw(a)kanga.nu --=| A man is as sane as he is dangerous to his environment |=--

2 2

Announcing Mailman 2.0 release candidate 1
by barry＠wooz.org 23 Oct '00

23 Oct '00

Hello folks, Okay, we're really close now! I've put together Mailman 2.0 release candidate 1 and uploaded it to SourceForge. You can grab the tarball from the file release page at http://sourceforge.net/project/shownotes.php?release_id=14446 www.list.org and www.gnu.org should be updated soon. This release contains a bunch of bug fixes and a few local security patches. The source code is essentially frozen, modulo any last minute show stopper bugs. I will probably make a pass at the documentation before the final release. Expect 2.0 final hopefully by the weekend. Enjoy, -Barry

1 0

Re: [Mailman-Developers] Security
by Dan Mick 23 Oct '00

23 Oct '00

> If I post to a specific list, or approve a held post for that > list, there is an 80% chance that this will crash the machine > (compleat lock, no interrupts, no useful log entries. What do you mean "crash the system"? Panic and coredump? Hang? Crash mailman/python and everything else is still up? If panic/coredump, some time spent in cursory kernel coredump analysis is warranted to point a finger at a culprit. Being a kernel developer, I'm biased, but when people say "crash the machine" that's what I think of. Is that what you mean?

1 0

CVS
by Phil Barnett 22 Oct '00

22 Oct '00

I asked on mailman-users and got no definative answer, and I have searched the mailman home page and everything it leads me to, but I can't find any place where the CVS is tarballed and ready to ftp. Is there such a place? Does anyone have any objection to my creating a CVS tarball on a daily basis and providing this service (assuming it is not already being done somewhere...)? -- Phil Barnett mailto:midnight@the-oasis.net WWW http://www.the-oasis.net/ FTP Site ftp://ftp.the-oasis.net

2 4

Re: [Mailman-Developers] Mailman-Bug with faked spam headers and some suggestions new features
by barry＠wooz.org 19 Oct '00

19 Oct '00

>>>>> "SB" == Steffen Bardolatzi <steffen(a)asta.uni-wuppertal.de> writes: SB> This looks like a nasty bug ... SB> Oct 08 23:53:01 2000 (25258) Delivery exception: read-only SB> character buffer, None Oct 08 23:53:01 2000 (25258) Traceback SB> (innermost last): File SB> "/var/mailman/Mailman/Handlers/HandlerAPI.py", line 82, in SB> do_pipeline SB> func(mlist, msg, msgdata) File SB> "/var/mailman/Mailman/Handlers/Hold.py", line 173, in process SB> if mlist.require_explicit_destination and \ File SB> "/var/mailman/Mailman/MailList.py", line 1208, in SB> HasExplicitDest addr = string.lower(addr) SB> TypeError: read-only character buffer, None This will be fixed in rc1. -Barry

1 0

QMail patches submitted to sourceforge
by Sean Reifschneider 19 Oct '00

19 Oct '00

Since SourceForge doesn't allow any lengthy descriptions of patches, let me describe them here. Patch ID 101660: Fixing some information in the README.QMAIL file. Patch ID 101845: Changed calling line in qmail-to-mailman.py program to include "preline" call. Added an entry in FAQ on why archiving doesn't work for QMail. Patch ID 101846: Added a default entry "MTA_TYPE", which can be used to trigger MTA-specific actions in other code. This is a port forward of the patch I submitted last year, which I believe was dropped. Defaults.py.in auto-detects QMail and sets MTA_TYPE accordingly. Changes "newlist" to output QMail specific text. Patch ID 101847: A contrib program which does log rotation and mails any messages in "errors" or "smtp-failures" to mailman owner. This is another patch I submitted last year which I believe was dropped. Enjoy, Sean -- Hell hath no fury, like a file-system scorned. -- Sean Reifschneider, 1998 Sean Reifschneider, Inimitably Superfluous <jafo(a)tummy.com> tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python

3 2

X-Mailman-Version: header field
by John A. Martin 19 Oct '00

19 Oct '00

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Will there be an option or an easy edit to not use the "X-Mailman-Version:" header field? It might be nice to have a ./configure option something like "--paranoid-advertiser" for those whose policy is to not advertise the specific version of daemons and the like. --paranoid-advertiser would not use the X-Mailman-Version header field , would not have the version number in the logo on the web pages, and would not otherwise advertise the version number. Presumably anybody smart enough to be paranoid would also be thoughtful enough to mention the version where appropriate when seeking help and so forth. :-) jam -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.3 (GNU/Linux) Comment: OpenPGP encrypted mail preferred. See <http://www.gnupg.org/> iEYEARECAAYFAjnhvcoACgkQUEvv1b/iXy9ukACfUfCP2nsoxa5UEtL7YSndpFld gV8AnjFJzJUacNqeInEONJfyjDmVo0Wm =mJty -----END PGP SIGNATURE-----

2 1

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

Mailman-Developers October 2000