Mailman 3 August 1999 - Mailman-Developers

mailman changes
by Ricardo Kustner 24 Aug '99

24 Aug '99

Hi, I've made some changes into the version of Mailman i'm using to make life a bit easier of our moderators (and me)... most of which are on the 'administrative requests' page (Mailman/Cgi/admindb.py) some of these changes are: 1) all mail headers of the moderated messages are filtered by default; only a few nesecary headers are printed. I've also added a button to view the posts with all headers in case that's needed for some reason. 2) i've added an extra text-field which can be used to enter an email address, and an extra button 'send copy' in the Approve/Reject/Discard list that will send a copy of the email to that entered email addy. my next step will be adding a 'comment' field that will add a "note from the editor" to a post that is being approved to be send to the mailinglist. If anybody thinks these changes can be useful for others too, please let me know, and i'll try to make a patch out of them... I must say that it wasn't easy to understand some parts of the source, things like val[2][1] aren't that obvious :) And since i'm a python-newbie i had some problems with NameErrors at first when i added some of my changes... ;) I've only focussed on Cgi/admindb.py so far (and partly ListAdmin.py).... also, i wanted to add some configuration options, but i couldn't find an easy way to do that without having to know the complete structure of the mailman sourcecode... so i gave up... for now... I also want to enhance the 'Membership Management' section (to be honest, it takes too much time to find a member through the webinterface), but i think i'll need a few more hours of studying the mailman source before i can do that I'm really interested in learing more about mailman and python... it has been a while since i learned something new with programming and i've just remembered how addicting it can be :) Ricardo. --

1 0

The Hylton Archiver Band-aid
by Barry A. Warsaw 21 Aug '99

21 Aug '99

I've just checked in a slew of changes affecting the archiver, hopefully fixing the more serious of the nasty performance problems we've been seeing. Jeremy Hylton deserves a lot of credit for his excellent analysis and patching of the code. He called his changes "a band-aid" because it's clear the archiver could still use more improvement, and in fact should go through a simplification and partial rewrite. We don't have the time for that now, so we'll go with the Hylton Band-aid for now. I hope I can accurately outline the changes, but it's late and I'm tired so I might miss something. Please check the CVS log messages for details. I really hope some of you adventurous types will try running with these new changes. I intend to put them up on python.org (perhaps this weekend, or Monday) to see if it fixes the performance problems I've been seeing there. First of all, Jeremy noticed that the way the archiver's .txt.gz file is created is very inefficient. It essentially reads the .txt and uses Python's gzip module to write the .txt.gz file -- for /every/ message that gets posted! This is a lot of work for not much benefit. So the first change is that the .gz file is not created by default (see mm_cfg.GZIP_ARCHIVE_TXT_FILES). We need to work in a crontab entry that gzip's the file nightly. Yes this means that the .txt.gz file will lag behind the on-line archive, but that should be a worthwhile tradeoff for better performance. Jeremy also changed the DumbBTree implementation so that the keys are not sorted until some client starts to iterate through the data structure. This saves work when adding the initial elements. Remember a while back I added a clear() method to do a bulk clear of the items and this saved a lot of work. Finally, Jeremy made some observations about the cache in the HyperDatabase. He says that since it traverses the elements in linear order, the lack of locality of reference means that evicting items from the cache doesn't really help, and in fact might hurt performance. So we now keep all the items in the cache (trade space for time). It might be worthwhile to get rid of the cache altogether, although it does serve a useful purpose currently. The DumbBTree is essentially a dictionary of pickles, and this whole structure is then marshaled. The cache keeps a hold of the unpickled objects. It might make sense then to make the DumbBTree a simple dictionary and just pickle it directly. Then the cache wouldn't be needed. Jeremy has some other ideas about how to improve the archiver. I'm way too tired to outline them here. Jeremy will be out of the office for a week, so hopefully he'll be able to restore enough state when he gets back to post his ideas. G'night, :) -Barry

1 0

Localization expert needed
by Guido van Rossum 19 Aug '99

19 Aug '99

My contact at HP is asking for expert advice on localization and multi-byte characters. I have little to share except pointing to Martin von Loewis and Pythonware. Does anyone on this list have a suggestion besides those? Don't hesitate to recommend yourself -- there's money in it! PS I'm not on the mailman-developers list, so please reply to me directly! --Guido van Rossum (home page: http://www.python.org/~guido/) ------- Forwarded Message Date: Wed, 18 Aug 1999 23:15:55 -0700 From: JOE_ELLSWORTH To: guido(a)CNRI.Reston.VA.US Subject: Localization efforts and state in Python. Hi Guido. Can you give me some references to The best references currently available for using Python in CGI applications when multi-byte localization is known to be needed? Who is the expert in this in the Python area? Can you recomend that they work with us in this area? Thanks, Joe E. ------- End of Forwarded Message

2 1

Re: [Mailman-Developers] Re: [Mailman-Users] Virtual Hosts -- can mailman handle them better?
by Harald Meland 19 Aug '99

19 Aug '99

[Tomas Fasth] > Tauren, Harald, > > I also have experienced problems with virtual hosting in > Mailman. That is, if you try to make it work within a single > installation. My solution was to install one instance of Mailman för > each virtual domain, each with it's own account (userid). Just a quick note: That would work OK for now, but wouldn't benefit as well as it could from the installation-global user database that's planned for next generation Mailman... Thanks for the tip anyway, -- Harald

2 1

RE: [Mailman-Users] Usability patch: (Details) Buttons for 1.0
by Ricardo Kustner 18 Aug '99

18 Aug '99

Hi, On 16-Aug-99 Bernhard Reiter wrote: > Mailman developers don't share my view on this so far, but I thought maybe > one > or the other user might be interested in it. With all respect to the great product the "core" mailman developers have created so far, i've noticed that it's not easy to get feedback from the developers when you post ideas/suggestions for mailman on the list... this way i (and maybe others too?) am not really motivated in sharing the changes or enhancements i make into mailman, which could be useful to other people too... Ricardo. --

3 6

submitting code
by Steven Hazel 18 Aug '99

18 Aug '99

I have a basic CGI set up to allow posting to mailman lists from a page in the mailman site. It involves one new file and changes to two other files. I've made it off the latest CVS source, so it should work with that. What's the best way to submit it? Do I just post the file and context diffs here? -S

1 0

news to mail gatewaying problem...
by Ronald A. Jarrell 18 Aug '99

18 Aug '99

This is actually a python bug, but it breaks mailman. The news to mail gateway stuff won't (can't in fact) work when mailman and the news server are the same machine (or if mailman is running on a machine with transfer privs to the news server), and the news server is INN. Apparently python's nntplib hasn't been updated in a LONG time; every other major library out there knows to issue a "mode reader" before trying to do anything as a reader on an inn server. It doesn't hurt if you're already in reader mode; it's vital if you aren't. A feeder connects to the inn daemon; which doesn't understand reader commands. "mode reader" causes it to fork off an nnrpd daemon which DOES understand reader commands... Which kinda stinks, since one of the main reasons I put mailman up on the news server was to replace the homebrew gateway stuff I was running... Sigh.

5 4

Re: [Mailman-Developers] RE: [Mailman-Users] Virtual Hosts -- can mailman handle them better?
by Harald Meland 18 Aug '99

18 Aug '99

[Tauren Mills] > I have set "Host name this list prefers" and it still returns emails > with the main domain name in them. Strange -- this certainly works fine for me, and I can't see any site-global configuration settings that could somehow inhibit changes done here. You're sure that it isn't your MTA that's rewriting the (header) addresses after Mailman has handed the message over to it? > > However, if you have several lists with the same localpart name in > > different domains (i.e. "foobar(a)dom1.com" and "foobar(a)dom2.org"), > > you'll have to assign them different Mailman-internal names. > > What do you mean by "different Mailman-internal names"? E.g. the list <mailman-users(a)python.org> has the Mailman-internal name "mailman-users". Thus, if the Mailman installation at python.org housed another domain "example.com" that wanted a list <mailman-users(a)example.com>, that list would have to use a different Mailman-internal name, e.g. "mailman-users-example.com" -- which would result in Mailman-generated messages looking rather messy, with email addresses like mailman-users-example.com(a)example.com all over them... If the Mailman-internal name was equal to the (preferred) email address of the list, there wouldn't be these kind of naming collisions. > But the problem is that the emails that get sent from Mailman would still > say "announce2(a)customerdomain.com" all throughout them, instead of > "announce(a)customerdomain.com". > > Would your suggested changes solve this problem? That is the main motivation for me suggesting it, so yes, I do hope it would :) > Could the newlist command at least include options on the command > line for the list's default URL and for the mail domain? What do others think about this? I'd really rather solve this once and for all with my proposed email-addr-as-internal-name and maildomain->base_URL scheme... but if no one but me think that that's the way to go, I probably won't bother :) Besides, I'm kind of swamped with real work right now :( -- Harald

4 3

RE: Mailman-Developers digest, Vol 1 #344 - 4 msgs
by Ken Manheimer 17 Aug '99

17 Aug '99

> From: "Tauren Mills" <tauren(a)servlets.net> > To: <mailman-developers(a)python.org>, "mailman-users" <mailman-users(a)python.org> > Date: Mon, 16 Aug 1999 01:05:44 -0700 > Subject: [Mailman-Developers] RE: [Mailman-Users] Virtual Hosts -- can mailman handle them better? > > It is good to hear that this is already supposed to work, but this is not > what I have experienced. I have set "Host name this list prefers" and it > still returns emails with the main domain name in them. Maybe I have > something configured incorrectly. I'll go poke around some more. It's likely that your MTA (sendmail, or whatever you're using) is doing this, not mailman. Try some experiments passing things directly to your MTA claiming to originate from your virtual host, and see if they get transformed on the way through. If not, i'm not sure what to suggest - i believe numerous people are using the virtual host mailman feature successfully. Re having mailman host multiple lists having the same list name but different domains, i think thomas fasth's suggestion is a good one - use separate mailman installs for separate lists. (You'll have to work out the MTA details to dispatch to the right mailman install according to the domain...) Making a single mailman handle multiple lists with the same apparent name would take another level of indirection in the mailman code on the maillist names, plus an option on the mailman pipe command lines. If you're interested, this is doable, but definitely not trivial. I doubt it will happen until someone directly needing it makes the effort. > > I'm not aware of any easy solution to that problem. Sure, we could > > add another option to the "newlist" script for specifying the list's > > default URL (and another for it's mail domain), but I don't think > > that's a particularly neat solution... > > We are trying to automate as much of our system as possible. We would love > to make it so that when a customer orders a mailing list service, it is > automatically installed and configured. With this in mind, it would really > make sense for the newlist command to be able to accept a bunch of command > line parameters instead of stdin. It's not an instead kind of thing - it does both. (At this point it may be worth "getting your hands dirty" reading a bit of mailman's python code. In particular, the docstring for the newlist command gives you the invocation info; there may be other questions you have that would be answered in a similar way...) > I think that there are many ISPs that would absolutely love a mailing list > system like Mailman if it had virtual hosting support built right in > flawlessly (we certainly would!). We've managed to tweak Majordomo a bit so > that it kind of works. And now we've kind of got Mailman working too. But > we really would like it to make our lives easier in a virtual hosting > environment, since that is pretty much all we do all day long. Clearly virtual hosting is important in the ISP world, and mailman certainly provides some capability there. However, we simply *can't* aim for flawless in any of the myriad dimensions where mailman operates - mailman has to do a lot of things well, not just any one thing. It's at these limits where open source, and a particularly comprehensible implementation language like python, can be a saving grace. There are limits in both directions, of course... Ken Manheimer klm(a)digicool.com

1 0

archive,multilang
by Bencsath Boldizsar 16 Aug '99

16 Aug '99

Hi, First of all, thanks for all developers contributing this software. Be proud of doing that. I have some notices, I think some asked for them before, but I didn't find on the TODO list. -It would be great to have language templates, so every site or user could see the web UI in his/her own language. This templates could be created as XML/DTD docs, or so, to provide more comfortable update mechanism (If XY makes the russian interface, but the central interface, so the english is changing, then the russian should be rewritten. If mailman would have a central doc-template format, then it would be more easy to change the document (language) format -As using mailman in Hungary I always met problems with spcial characters. Now one problem is reading archives on the web like this one: [Nov7] =?iso-8859-1?Q?=E9ljen?= a forradalom! Szekfu Balazs Other problem is using mime attachments etc in the archives. The solution is not easy. To read all messages as it could be read on a mail client is a bigger problem than writing a mail reader because of the web interface's problems. The first functional workaround could be if an archive-reader would able to press a "send this messages to me by email" button or press a "forward this to.." button... Of course some lists have new members who wish to read many older messages... so "get gzipd archive"" for this month could be extended to "get all messages by email gaain". There are problems.If the archive is public, then it could be used to email-bomb a person's email box. At the other hand a bad email address could cause problems on the mailman server ( if i send tousands of messages to unknown recipients). So I don't know the best answer, but now only sysadmins are trained enough to excavate an archive messages as readable as it should be. thanks, boldi

1 0