Mailman 3 July 2001 - Mailman-Developers

Re: [Mailman-Users] OpenBSD Trusted Path Execution (TPE) compatibility?
by barry＠digicool.com 10 Jul '01

10 Jul '01

>>>>> "JJ" == Joshua Jore <moomonk(a)daisy-chan.org> writes: JJ> No, but it would require than /home/mailman be owned by JJ> root. Which reminds me: I've been thinking about changing the default $prefix to be /usr/local/mailman in MM2.1. It makes much more sense to me and is in fact, what I use for all my new lists these days. You would, of course, be able to give configure --prefix=/home/mailman to get the MM2.0 default. Would that cause undo hardship to folks? -Barry

3 2

No module named RFC822
by Georg Koch 10 Jul '01

10 Jul '01

Before sending in another peculiar observation, I wanted to update my mailman version. After "cvs update" I did a "make install" and got the following error: Compiling /home/mailman/Mailman/versions.py ... Traceback (most recent call last): File "bin/update", line 46, in ? from Mailman import MailList File "/home/mailman/Mailman/MailList.py", line 49, in ? from Mailman.Bouncer import Bouncer File "/home/mailman/Mailman/Bouncer.py", line 29, in ? from mimelib.RFC822 import RFC822 ImportError: No module named RFC822 Normal sending with known subscribers seems to work, but senddigests now complains with the same error: /usr/local/bin/python /home/mailman/cron/senddigests produced the following output: Traceback (most recent call last): File "/home/mailman/cron/senddigests", line 25, in ? from Mailman import MailList File "/home/mailman/Mailman/MailList.py", line 49, in ? from Mailman.Bouncer import Bouncer File "/home/mailman/Mailman/Bouncer.py", line 29, in ? from mimelib.RFC822 import RFC822 ImportError: No module named RFC822 What should I do? Best wishes Georg -- -- Georg Koch ( mailto:gorg@cochrane.de ) | Phone: +49 761 203 6710 German Cochrane Centre | Fax: +49 761 203 6712 Mail: Institute of Medical Biometry and Medical Informatics Stefan-Meier-Strasse 26, D-79104 Freiburg, Germany ...................................................................... Crossing the Quality Chasm: A New Health System for the 21st Century http://www.nap.edu/books/0309072808/html/

3 2

Re: [Mailman-Users] Poking and prodding the archiver
by barry＠digicool.com 10 Jul '01

10 Jul '01

[Note: this discussion is more appropriate for mailman-developers, so I've changed the Cc: -baw] >>>>> "PS" == Phil Stracchino <alaric(a)babcom.com> writes: PS> I've looked at some length through the code for the archiver PS> now, and although I still don't understand python, I've PS> figured out enough of what the archiver is doing to see that PS> it's apparently intentional that the path to mbox archives is PS> .../mailman/archives/private/list.mbox/list.mbox. Yes, and this is for security reasons as explained in the comment in Archiver.py (see InitVars()). The comment is slightly out-of-date in that the file under listname.mbox/ is also called listname.mbox. PS> What I haven't been able to figure out is *why* the code is PS> written to duplicate the last element in the pathname; See above. PS> nor why it is that the archiver is written in such a way that PS> it attempts to access this mbox archive directory with its PS> duplicated final pathname element even when mbox archives are PS> disabled, and fails if it doesn't exist. If this is true (and I haven't tested it), then it's most likely just old lurking bugs. The archiver/Pipermail stuff is the most neglected part of the codebase. People keep threatening to help rewrite it, but so far nothing's materialized, and I have little time or energy to devote to the Pipermail side. PS> I find this behavior even more curious in light of the fact PS> that newlist apparently creates archives/private/list.mbox PS> when it sets up the list, but does not create the PS> archives/private/list.mbox/list.mbox without the existence of PS> which the archiver fails. Do you mean the archiver fails or that the web access to the archiver fails? Certainly not the former (unless I misunderstand) because it works for me, and loads of other people. It's a known buglet that the pipermail url doesn't work until the first message is posted to the list. PS> I've applied the following patch to my HyperArch.py file PS> (patch also attached separately): [patch deleted] PS> I don't know what impact this has on mbox archives, but for PS> me, it makes the HTML archiver work. Hmm, odd. What I think will break is private archives. If you toggle an archive to private, I seem to remember that you can craft a url to trick the web server into vending an archive page for you directly, instead of forcing you to go through authentication with the private.py cgi. PS> I would welcome comment, any explanations for the curious PS> state of unsatisfied and illogical dependencies described PS> above, and any advice on fixing anything that this patch PS> breaks. It's still a mystery to me why the archiver should PS> even *care* whether or not the mbox archive directory exists, PS> when mbox archives are disabled in the master configuration PS> anyway. It probably shouldn't, but then Mailman probably shouldn't support ARCHIVE_TO_MBOX=0. Archiving to the mbox is about as fast as it gets, since it is just a file append, and it's /incredibly/ handy to have that .mbox file around (even as large as it can get), in case you want to regenerate your archive, or you want to migrate to a different external archiver. -Barry

2 1

Templates..
by Morten Werner Olsen 06 Jul '01

06 Jul '01

Hello. I try to change Mailman's look to make it fit into another web-interface, but because of some reason it's not enough to change the templates in /etc/mailman. One of the problems is the subscribe.html-file. I change it to what I want, but when it's shown, these four lines is printed in the top (and they are not from the template-file): <HTML> <HEAD> </HEAD> <BODY bgcolor="#ffffff"> Why, and is it a way I can stop this from happening? It destroys my bgcolor.. :) Best regards, Morten Werner Olsen.

3 2

encrypted mailinglists
by Achim Gaedke 06 Jul '01

06 Jul '01

Hello everybody! I wonder if you are interested in encrypted mailinglists. My ideas are: - Using pgp or gpg as encryption algorithm. - The list administrator/moderator generates a list key. - Everything, what is going to the list is encrypted with this public key (mails, subscription ...) - Outgoing mails are encrypted with the public keys of the list members. - If a new member wants to join this list, she/he must be approved by the moderator (otherwise, encryption does not make sense...), support for checking fingerprints of public keys and chains of trust would be nice. - Instead of encryption, signatures are added. I have no time to contribute jet, but maybe someone else is concerned with developing such a mailingist. Bye, Achim -- Achim Gaedke, ZPR Weyertal 80, 50931 Köln Tel: +49 221 470 6021

1 0

error with latest CVS: len() of unsized object
by Mentor Cana 06 Jul '01

06 Jul '01

All... Here is the error logged after I send a message to a test list on the latest mailman CVS installation. I CVSed today's set of checkings... The message gets stuck in qfiles/shunt directory. -- Mentor ---------- Jul 05 18:54:08 2001 (23307) Uncaught runner exception: len() of unsized object Jul 05 18:54:08 2001 (23307) Traceback (most recent call last): File "/opt/home/mmtest/Mailman/Queue/Runner.py", line 102, in __oneloop self.__onefile(msg, msgdata) File "/opt/home/mmtest/Mailman/Queue/Runner.py", line 142, in __onefile sender = msg.get_sender() File "../Mailman/Message.py", line 66, in get_sender File "/usr/local/lib/python2.0/site-packages/mimelib/address.py", line 16, in getaddresses return a.getaddrlist() File "/usr/local/lib/python2.0/rfc822.py", line 522, in getaddrlist ad = self.getaddress() File "/usr/local/lib/python2.0/rfc822.py", line 530, in getaddress self.gotonext() File "/usr/local/lib/python2.0/rfc822.py", line 510, in gotonext while self.pos < len(self.field): TypeError: len() of unsized object

2 1

Re: [Mailman-Developers] Want to Code... need some feedback
by J C Lawrence 05 Jul '01

05 Jul '01

On Thu, 05 Jul 2001 14:16:53 -0700 Charles Iliya Krempeaux <tnt(a)linux.ca> wrote: > Hello, J C Lawrence <claw(a)kanga.nu> wrote: >>> To do this, I think that e-mail messages should be dumped into a >>> database. (Since I have MySQL and PostgreSQL at my disposal, >>> those are what I'll be able to support myself.) >> I have some early proof of concepts done on having MHonArc >> generate scripts which when executed insert their respective >> message contents into PostgresQL with the appropriate threading >> links. The code is based off the PHP and templated based >> archiving I already do at Kanga.Nu, merely taking the already >> products PHP variable assignments in the current system and >> insteaf having the back end use them as the values to insert into >> the DB. >> >> It works. Kinda. Its not pretty. The reliance on PHP as an >> intermediate layer should be removed (slightly messy as MHonArc >> insists on inserting HTML-style comments), Proper thread handling >> and generation needs to be improved (Shouldn't reluy on MHonArc >> but should be dynamically generated). etc. > My way of thinking, of having it designed, is that Mailman (using > Python) directly dumps the e-mail messages into the database. <nod> > (Are there standard [or defacto standard] Python modules for > accessing databases?... For accessing MySQL and PostgreSQL?) Yes. > Then, standard PHP (and whatever other languages) > bindings/libraries, to the database, can be provided. That way, > the database is the middle man. And Mailman, and the PHP > binding/library (and any other language binding/library) only > depend on the database. (And better still, Mailman is completely > independent of the PHP [and vice versa]. Only the database > structure matters.) The reasons I don't want to do this: 1) MIME 2) national (and other) character sets 3) content types (really a subset of MIME but a large enough problem to be unique) > (To get a little deeper into the design...) the important things I > see, to extract from each message (and also store), is: Minimally: To: (multiple) From: CC: To: GECOS (multiple) From: GECOS CC: GECOS (multiple) Date: Receipt date Receipt address(es) (multiple) MessageID References: (multiple) In-Reply-To: (computed it missing, flagged) Subject: Prior subject (was: (...) matching, opportunistic history match) Message Body MIME Key (if any) MIME structure Indexes to external MIME items -- J C Lawrence claw(a)kanga.nu ---------(*) http://www.kanga.nu/~claw/ The pressure to survive and rhetoric may make strange bedfellows

1 0

Re: [Mailman-Developers] Want to Code... need some feedback
by Charles Iliya Krempeaux 05 Jul '01

05 Jul '01

Hello, J C Lawrence <claw(a)kanga.nu> wrote: >> To do this, I think that e-mail messages should be dumped >> into a database. (Since I have MySQL and PostgreSQL at my >> disposal, those are what I'll be able to support myself.) > > I have some early proof of concepts done on having MHonArc generate > scripts which when executed insert their respective message contents > into PostgresQL with the appropriate threading links. The code is > based off the PHP and templated based archiving I already do at > Kanga.Nu, merely taking the already products PHP variable > assignments in the current system and insteaf having the back end > use them as the values to insert into the DB. > > It works. Kinda. Its not pretty. The reliance on PHP as an > intermediate layer should be removed (slightly messy as MHonArc > insists on inserting HTML-style comments), Proper thread handling > and generation needs to be improved (Shouldn't reluy on MHonArc but > should be dynamically generated). etc. My way of thinking, of having it designed, is that Mailman (using Python) directly dumps the e-mail messages into the database. (Are there standard [or defacto standard] Python modules for accessing databases?... For accessing MySQL and PostgreSQL?) Then, standard PHP (and whatever other languages) bindings/libraries, to the database, can be provided. That way, the database is the middle man. And Mailman, and the PHP binding/library (and any other language binding/library) only depend on the database. (And better still, Mailman is completely independent of the PHP [and vice versa]. Only the database structure matters.) (To get a little deeper into the design...) the important things I see, to extract from each message (and also store), is: The author of the message. (This will probably be based on the e-mail address. But, IMO, it would be better to design it so a person/author is thought of as a seperate entity from an e-mail address. That way, a person/author could have more than one e-mail address, and still be recognized as the same person/author. There is one problem though... what happens if more than one person uses an e-mail address?) The message (or possiblely messages) that the e-mail message is a response to. The mailing list (or mailing lists) that it was sent to. The date & time it was received by the mailing list. The date & time it was (suppose) to have been sent. (Although this can be inaccurate when someone does not set their clock correctly,... as I understand it anyways.) The subject of the message. Other `things' that might want to be stored. (Maybe for statistical reasons. Maybe for other reasons.) The delivery history of the of the e-mail message. All the other headers found in the message. If a message is sent from the web interface, maybe store stuff like the IP address of the sender, etc. Does that sound reasonable? Have I missed anything? Your insight into the workings of Mailman would be much appreciated. See ya Charles Iliya Krempeaux

1 0

Re: [Mailman-Developers] Want to Code... need some feedback
by J C Lawrence 05 Jul '01

05 Jul '01

On Thu, 05 Jul 2001 11:55:03 -0700 Charles Iliya Krempeaux <tnt(a)linux.ca> wrote: > To do this, I think that e-mail messages should be dumped > into a database. (Since I have MySQL and PostgreSQL at my > disposal, those are what I'll be able to support myself.) I have some early proof of concepts done on having MHonArc generate scripts which when executed insert their respective message contents into PostgresQL with the appropriate threading links. The code is based off the PHP and templated based archiving I already do at Kanga.Nu, merely taking the already products PHP variable assignments in the current system and insteaf having the back end use them as the values to insert into the DB. It works. Kinda. Its not pretty. The reliance on PHP as an intermediate layer should be removed (slightly messy as MHonArc insists on inserting HTML-style comments), Proper thread handling and generation needs to be improved (Shouldn't reluy on MHonArc but should be dynamically generated). etc. -- J C Lawrence claw(a)kanga.nu ---------(*) http://www.kanga.nu/~claw/ I never claimed to be human.

1 0

Want to Code... need some feedback
by Charles Iliya Krempeaux 05 Jul '01

05 Jul '01

Hello, When it comes to Mailman, I'm a newbie, and some of my understanding of Mailman is probably naive or just plain wrong. But I'd like to do some coding on Mailman. (And with the help of J C Lawrence <claw(a)kanga.nu> and Devdas Bhagat <devdas(a)worldgatein.net> [on the Mailman-Users mailing list] I think I have enough of an understanding of how Mailman works to attempt to get started.) It's my hope that maybe someone code point me in the right direction, of where to get started (to start coding). For example, should I use the 2.0.5 source, or should I get the source directly from the CVS? Also, what is the usual work environment that people use to develop? Mailman with Sendmail? Mailman with Qmail? Mailman with exim? Mailman with PostFix? Etc? Does it matter? Also, I'd like to describe my ideas (to everyone) to get some feedback. (Tell me if the ideas are good. If they suck. Or if someone is already doing them.) Anyways, here's my intention.... It is my opinion that the current web based archive system leaves much to be desired (in terms of usability, funtionality, and even aesthetics). And I'd like to see it improved; or at least provide the ability from website creator to improve them. (And if noone else is working on these things, I'd like to do them myself.) I'd like to say straight off, that I do not really know anything about the internals of Mailman, except that it is coded in Python. (I haven't yet begun reading the souce.) But anyways.... I think that the interface for the archiver would be more usable if it was more like that of a Weblog or Bulletin Board. From this Weblog or Bulletin Board like interface [of the mailing list archiver] the user could see the `traffic' of one single mailing list, or see the `traffic' of many different mailing lists. Also, the users of this interface, would have other functionalities at their displosal; like searching. Also, the archiver's webpage could also serve as a kind homepage for the mailing list. Providing additional functioanlity, like FAQs, Links, etc. (I'm expecting this to get some critisizm.) Further, the Weblog or Bulletin Board interface could also serve as an additional way of users being able to post messages to the mailing list(s). (Basically, my intention is to blur -- from the user's perspective -- the difference between a Mailing List, and a Weblog or Bulletin Board.) To do this, I think that e-mail messages should be dumped into a database. (Since I have MySQL and PostgreSQL at my disposal, those are what I'll be able to support myself.) I am assuming that the current archiver for Mailman doesn't do this already, but instead uses some kind if file format. Is this correct? Also, I think it is a good idea to provide a gerenal PHP (and whatever other language) library for accessing to archive (in the database). That way the database structure, for the archiver, is free to change, without necessarily breaking everyone else's code. And websites can completely and seemlessly integrate the archiver into their website (by creating their own front ends, using the PHP [or whatever language] library). Also, a default Web based user interface should be provided (using the PHP library). (For those user's who don't want to do any coding.) Those are the basics of what I'd like to do. (I'll leave it at that, to get some feedback, before describing things further, or in more detail. But there is alot more to it. Stuff that would affect other parts of Mailman too,... besides just the archiver.) See ya Charles Iliya Krempeaux

1 0