Mailman 3 June 2000 - Mailman-Developers

SMTPDirect doesn't log to 'posts'
by Dan Mick 21 Jun '00

21 Jun '00

Just decided to be brave and install the current 2.0 CVS on top of my 1.1 list. So far so good....but I see no posts in "logs/post". Is this intentional with SMTPDirect (the default Handler), and if so, why? post is a useful little log to make sure things are getting through.

1 0

Re: [Mailman-Developers] Wildcards in E-mail list...
by Dan Mick 21 Jun '00

21 Jun '00

paul wrote: > > Is there a way to use wildcards in the "Addresses of members accepted for > posting"(privacy options) box ? It looks to me like the answer is "no" for 1.1, and I don't see anything different for 2.0.

1 0

Wildcards in E-mail list...
by paul 21 Jun '00

21 Jun '00

Is there a way to use wildcards in the "Addresses of members accepted for posting"(privacy options) box ? Thanks ___________________________________________________________ Paul Faure paul(a)engsoc.carleton.ca

1 0

Re: [Mailman-Developers] ZODB and ZEO for mailman
by J C Lawrence 21 Jun '00

21 Jun '00

On Tue, 20 Jun 2000 19:32:36 -0400 (EDT) Jim Hebert <jim(a)cosource.com> wrote: > To some, making mailman depend on peices of zope might be > ornerous, but to me it's a better call than hooking it directly up > to something like postgres (which I've heard batted around) and > gets you a whole lot more, too... The problem with this is that there are a large number (majority?) of Mailman users who specifically don't want to run Zope but do want to run Mailman. Bolting the ZODB underneath Mailman is not a Bad Idea, but at the same time, for sites that already have all their data in an SQL database, it doesn't solve their problems of integrating Mailman with their other infrastructure (web acocunts, LDAP, customer catabases, third part databases, etc). As such, Mailman moving to ZODB for them is a losing situation. Should Mailman gain a database abstraction which allows ZODB or a variety of SQL databases to be plugged in underneath, everybody wins _and_ you provide an easy migration path for those people who later want to move over to Zope proper. -- J C Lawrence Home: claw(a)kanga.nu ----------(*) Other: coder(a)kanga.nu --=| A man is as sane as he is dangerous to his environment |=--

5 6

ZODB and ZEO for mailman
by Ken Manheimer 21 Jun '00

21 Jun '00

When i left CNRI for Digital Creations, i thought i might continue with mailman development, but that didn't wind up happening. However, i'm still pretty darn enthusiastic about the benefits of using Zope stuff for mailman, and seeing Andrew Kuchling's recent ZODB/ZEO introduction: http://starship.python.net/crew/amk/python/writing/zodb-zeo.html brings home the point pretty well - i think many of mailman's burning issues would best be solved using ZODB and ZEO. ZODB is the Zope Object DataBase, and ZEO is the Zope Enterprise Option - multiple concurrent access to a single database. Where would this help? Lots and lots of places. Mailman wants a persistent object store, badly. Anytime mailman does something with a maillist, an instance of the Maillist class is instantiated, which then fetches its instance information from a marshalled dictionary in the filesystem. Unless the activity is sure to *not* involve any state changes, the maillist in question is locked - since multiple instances of the maillist are separate copies. ! Lots of stuff is jammed into the current, feeble persistence mechanism, beyond the basic maillist state - stuff like subscriber information, messages caught for administrative approval (though that may be changing), maybe other stuff. This means that not only are multiple concurrent instances of a maillist distinct, disassociated copies, but also that there's no way to share these other components between them, without going to other storage. (Other storage, eg the filesystem, for things like the message delivery queues.) Imagine, instead, that maillist instances and the other components were implemented as persistent objects in the ZODB, which is reached from the web, email, news, and command line interfaces with lightweight scripts that plug into ZEO. ZODB, being transactional, would handle conflict resolution - no more locking performance or misbehavior hassles - and the Connection class cache would take care of rolling stuff in and out based on activation, for good responsiveness and memory performance. Messages going through the system could be implemented as persistent objects in their own right. This is useful for mediated transmission through the message pipline, and also for retention for archival purposes. (Maybe the message store would be a separately mounted ZODB, tuned for use as a smart archive, with provisions for good cataloguing, message annotations, etc.) Multiple threads in the delivery pipeline could be processing the messages at once - for parallel news gatewaying and mail transmission. Messages held for approval would already be in a kind of archive - currently, they're held as message objects in the respective maillists, and are marshalled and unmarshalled with the maillist state. Bogus! How are subscribers currently represented? Urgh. Last i knew, they were manifest in scattered places in the maillist structure - entries in the members or digest_members attributes, for membership info, with parallel entries in the passwords (or somename like that) dictionary, and probably elsewhere. Unless this has since changed, they weren't instance objects, but scattered data, and most importantly, they're specific to each list. Bogus! This last may be the most telling failing of the current maillist- marshal based persistence mechanism - it's neither unified nor transparent, so there's no easy way to share state between lists. Judicious use of ZODB plus ZEO could solve all that, making it easy to represent the components of the system - mailling lists, members, messages, etc - as real objects, with transparent, transactional persistence and concurrent access built in. My cries of "bogus", above, should not be taken as condemnation. I still think mailman is great - i'm pretty pleased to see the way it has taken off. I do think that the current architecture has severe limitations, in particular, it will continue to involve great pain with filesystem locking, obstruction to unified membership, etc. And i think that a concurrent persistent object system is the right way to deal with this - and ZODB plus ZEO are just about ideal prospects for providing that... Take a look at the andrews description - http://starship.python.net/crew/amk/python/writing/zodb-zeo.html Ken Manheimer klm(a)digicool.com

3 3

Bug#65955: Resent-To and Resent-Cc should be considered explicit destinations. (fwd)
by Gergely Madarasz 20 Jun '00

20 Jun '00

A small bug, with a patch included... -- Madarasz Gergely gorgo(a)sztaki.hu gorgo(a)linux.rulez.org It's practically impossible to look at a penguin and feel angry. Egy pingvinre gyakorlatilag lehetetlen haragosan nezni. HuLUG: http://mlf.linux.rulez.org/ ---------- Forwarded message ---------- Date: Tue, 20 Jun 2000 15:09:05 +0200 From: Thomas Quinot <quinot(a)ada.eu.org> To: Debian Bug Tracking System <submit(a)bugs.debian.org> Subject: Bug#65955: Resent-To and Resent-Cc should be considered explicit destinations. Resent-Date: Tue, 20 Jun 2000 14:59:53 +0000 (GMT) Resent-From: Thomas Quinot <quinot(a)ada.eu.org> Resent-To: debian-bugs-dist(a)lists.debian.org Resent-cc: Gergely Madarasz <gorgo(a)sztaki.hu> Package: mailman Version: 1.1-6 Severity: normal Currently, mailman only takes To: and Cc: headers into account to determine whether a message was explicitly sent to a mailing list. The Resent-To: and Resent-Cc: headers should be used as well. The following patch is a proposed solution to this problem: --- MailList.py.dist Thu Jun 1 00:26:48 2000 +++ MailList.py Tue Jun 20 15:04:06 2000 @@ -1118,7 +1118,8 @@ lowname = string.lower(self.real_name) recips = [] # First check all dests against simple name: - for recip in msg.getaddrlist('to') + msg.getaddrlist('cc'): + for recip in msg.getaddrlist('to') + msg.getaddrlist('cc') \ + + msg.getaddrlist('resent-to') + msg.getaddrlist('resent-cc'): curr = string.lower(string.split(recip[1], '@')[0]) if lowname == curr: return 1 -- System Information Debian Release: 2.2 Architecture: sparc Kernel: Linux marvin 2.2.14 #2 Mon Feb 21 16:52:43 CET 2000 sparc64 Versions of packages mailman depends on: ii apache 1.3.9-13.1 Versatile, high-performance HTTP s ii apache [httpd] 1.3.9-13.1 Versatile, high-performance HTTP s ii cron 3.0pl1-57 management of regular background p ii libc6 2.1.3-10.0.1 GNU C Library: Shared libraries an ii logrotate 3.2-11 Log rotation utility hi postfix [mail-transpo 0.0.19991231pl05-2 A mail transport agent ii python-base 1.5.2-10 An interactive object-oriented scr

1 0

Possible MIME bug
by Johnson, April 19 Jun '00

19 Jun '00

We've encountered a problem that may be a bug. It is caused when HTML-style email is posted to the mailing list from MS Outlook Express for Macintosh (version 4.5 and 5 tested, possibly also Eudora). The MIME data from the Outlook email cannot be correctly interpreted, so the MIME headers show up in the email contents. Is this a known bug? Is there a fix available? April Johnson Xperts, Inc. (804) 967-0700 x174 http://www.xperts.com http://www.xperts.org

1 0

explicit bulk approval
by David Champion 19 Jun '00

19 Jun '00

Three alternate proposals: 1. Implicit-approval addresses supercede "too many recipients" blocking -- i.e., if sender matches "posters", then "max_num_recipients" is irrelevant. 2. Same as #1, but only if some new boolean is true. 3. Same as #1, but using a different address list than "posters". (Slap me, please, if this is already in a newer version of Mailman.) Do these seem good? I have no idea whether I can do them, so if someone else wants to, be my guest. It would be a while before I get to it since I need to learn more Python first. -- -D. dgc(a)uchicago.edu NSIT University of Chicago

1 0

Issues With Mailman 2.0 upgrade
by John MacKenzie 19 Jun '00

19 Jun '00

Hey guys, Since upgrading to the beta I've had issues sending some of my lists. On certain lists when I go to approve It waits a little while and then returns with a "document contained no data" box. Other lists Work fine but it just happens with these certain ones (it would appear that its just the ones with high volume subscribers. Anyone Know the cause of this and how to sort it ? Cheers - John -- John MacKenzie | Unix Systems Admin | e: mailto:jmackenzie@local.ie ___________________________________________________________________ Stay in touch your local area through Local Ireland http://chat.local.ie/chat/index.html ___________________________________________________________________ local ireland | dublin | new york | http://www.local.ie t: +353 1 676 8996 f: +353 1 283 9988

1 0

mailman seems to ignore Content-Transfer-Encoding
by Michael Sobolev 19 Jun '00

19 Jun '00

I have a problem here. It's pretty simple (I believe).. :) The messages sent to the mailling list have Content-Transfer-Encoding equal to base64 or quoted-printable. Mailing list software just adds its usual blah-blah-blah (mailing-list, url, etc). When such a message arrives to the recipient, MUA processes the body according to the header's value, and the users sees garbage. What can I do (beside modifying the source :)? Thanks, -- Misha

1 0