Mailman 3 March 2003 - Mailman-Developers

delete list that have space
by mr_zali 14 Mar '03

14 Mar '03

Hi, I create a list named free software. But how i want to delete the list. Using 'rmlist' command still no effect. I'm using Mailman-2.0.12.

1 0

[Mailman-Developers] Updated patch that allows posting authorization for members of other lists
by Nathan Neulinger 13 Mar '03

13 Mar '03

This patch allows you to specify +listname in the accept_these_nonmembers, hold_these_nonmembers, reject_these_nonmembers, and discard_these_nonmembers boxes in the list configuration, and will dynamically include the members of those lists. This is very useful when you have lists that forward to other lists. For example: mygroup-leaders mygroup-helpers mygroup-workers with mygroup-all forwarding to each of the above. You could put +mygroup-helpers +mygroup-workers +mygroup-leaders in the accept box for each of those lists, and it will allow any of the members of any of the lists to post to the mygroup-all list. Or similar affect for other configurations. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul(a)umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216

1 0

[Mailman-Developers] patch to add a DEFAULT_UCFIRST_REAL_NAME option
by Nathan Neulinger 13 Mar '03

13 Mar '03

This patch adds a DEFAULT_UCFIRST_REAL_NAME option, defaulting to 1, which allows site admin to request that new lists all be created with the list name being all lowercase by default, instead of the mixed case name. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: nneul(a)umr.edu University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216

1 0

Serious bug shunting messages
by Daniel Buchmann 13 Mar '03

13 Mar '03

Sorry, didn't have the time to look if there already was a bug report on SF for this one... I'm getting this traceback and a lot of files in qfiles/shunt/, seems to be something with digests and i18n? List language is Norwegian. Mar 12 22:47:24 2003 (10688) Traceback (most recent call last): File "/home/mailman/Mailman/Queue/Runner.py", line 105, in _oneloop self._onefile(msg, msgdata) File "/home/mailman/Mailman/Queue/Runner.py", line 155, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman/Mailman/Queue/IncomingRunner.py", line 130, in _dispose more = self._dopipeline(mlist, msg, msgdata, pipeline) File "/home/mailman/Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/home/mailman/Mailman/Handlers/ToDigest.py", line 82, in process send_digests(mlist, mboxfp) File "/home/mailman/Mailman/Handlers/ToDigest.py", line 123, in send_digests send_i18n_digests(mlist, mboxfp) File "/home/mailman/Mailman/Handlers/ToDigest.py", line 295, in send_i18n_digests msg = scrubber(mlist, msg) File "/home/mailman/Mailman/Handlers/Scrubber.py", line 264, in process part.set_payload(_("""\ File "/home/mailman/Mailman/i18n.py", line 78, in _ return _translation.gettext(s) % dict UnicodeError: ASCII decoding error: ordinal not in range(128) This is giving me a major headache... I'm having 60+ messages stuck in the shunt queue, and people complaining about lists not working, messages not getting through, etc... anyone else seen this? I'm using latest Release_2_1-maint CVS branch...

4 7

Bad "Uncaught bounce" [forwarded]
by Martin Maechler 13 Mar '03

13 Mar '03

Dear Mailman developers, first, thanks a LOT for the great software! Since I didn't find it easy to submit a bug report (for mailman 2.1) --- it was easy to **browse** bug reports, but not to submit via sourceforge --- I allow myself to forward this to you. Note this is one of many "Uncaught bounce notification"s I'm getting --- which clearly should have been caught. An even clearer one, yesterday was "User unknown" : ----- The following addresses had permanent fatal errors ----- <mathie.roelants(a)vub.ac.be> ----- Transcript of session follows ----- ... while talking to akasolvr.vub.ac.be.: >>> RCPT To:<mathie.roelants(a)vub.ac.be> <<< 553 <mathie.roelants(a)vub.ac.be>... User mathie.roelants unknown at vub.ac.be 550 <mathie.roelants(a)vub.ac.be>... User unknown ----- Message header follows ----- Thanks a lot for hints, Martin Maechler <maechler(a)stat.math.ethz.ch> http://stat.ethz.ch/~maechler/ Seminar fuer Statistik, ETH-Zentrum LEO C16 Leonhardstr. 27 ETH (Federal Inst. Technology) 8092 Zurich SWITZERLAND phone: x-41-1-632-3408 fax: ...-1228 <><

1 0

Mailman 2.1 Topics for Dummies
by Terri Oda 12 Mar '03

12 Mar '03

I'm writing the mailman list subscriber documentation and I'm trying to find a good way to explain how topics work. Most if it isn't too hard to do, but, unfortunately, I'd have to explain regular expressions to people for them to be able to look at any topic and figure out how to post to it. That seems a little excessive, so I've simplified and just give examples to show some things which they're likely to encounter. But I wonder... Wouldn't it be easier if Mailman could just *tell* people what needs to appear in their subject line or keywords line when they click on the details of any given topic? If your topic regexp is something like \[Networking\] then it's not going to be inherantly obvious to everyone that that means you put [Networking] in your Subject line, and if people make the logical error of using \[Networking\] in their subject line, it won't work. I'm not sure the best way to avoid this... maybe something which gives a minimally matching expression so if someone checks the details for the networking topic, they see: Name: Networking course Pattern (as regexp): \[Networking\] Description: Networking course for complete beginners wishing to establish a simple home newtork To post under this topic , put "[Networking]" (witout the quotes) into the Subject: or the Keywords: line in your message. (These lines can also appear in the first X lines of the body of your message.) I know, I can put this into the description, but we can't assume everyone will do this, and right now the member interface doesn't even mention how this matching is done -- for all the subscriber knows, the pattern could match on the entire message! The suggested tag for posting could be generated from the regular expression or inputted by the admin. Also, does it say anywhere that this is done case-insensitively? I didn't see it when I was glancing around, but it's possible that I missed it. If it doesn't say so, can we make it say so somewhere? It should say so at least in the admin pages, but I can't think of any good reason not to mention it on the member options page too. Terri

1 0

Strip out attachments in the archive
by Niklas Nikitin 12 Mar '03

12 Mar '03

Hi, I am running Mailman 2.1.1 on our server. Today I disallow archiving, but I want to allow archiving for all lists. "My" users have the habit to attach huge documents to the e-Mail's, so I do not want to archive the attachments. I still want the attachments to be sent to all members on the list. In the archive I want to strip out the attachment and keep the rest of the document (and if possible to add a line like: "An attachment have been removed"). Can this be done, and if so how? TIA Niklas

1 0

Can't create list from web
by Stonewall Ballard 08 Mar '03

08 Mar '03

I'm running 2.1+ (just updated it), and have discovered that I can't create lists from the web anymore. I get this: Traceback (most recent call last): File "/usr/local/mailman/scripts/driver", line 87, in run_main main() File "/usr/local/mailman/Mailman/Cgi/create.py", line 55, in main process_request(doc, cgidata) File "/usr/local/mailman/Mailman/Cgi/create.py", line 176, in process_request mlist.Create(listname, owner, pw, langs) File "/usr/local/mailman/Mailman/MailList.py", line 444, in Create self.InitVars(name, admin, crypted_password) File "/usr/local/mailman/Mailman/MailList.py", line 362, in InitVars baseclass.InitVars(self) File "/usr/local/mailman/Mailman/Archiver/Archiver.py", line 91, in InitVars os.mkdir(self.archive_dir()+'.mbox', 02775) OSError: [Errno 13] Permission denied: '/usr/local/mailman/archives/private/actnetmembers.mbox' The list itself is not created (not listed by bin/list_lists). A directory of that name is created in the lists directory, but it's empty and it has its permissions set incorrectly (the group "s" bit is not set). I deleted the empty directory and used bin/newlist to create it. This time it worked, but the permissions were still wrong. check_perms complained: directory permissions must be 02775: /usr/local/mailman/archives/private/actnetmembers (fixing) directory permissions must be 02775: /usr/local/mailman/archives/private/actnetmembers.mbox (fixing) directory permissions must be 02775: /usr/local/mailman/lists/actnetmembers (fixing) I have not created a list since I updated to 2.1, and since I updated my server to OS X Jaguar (10.2.4) Server. Any ideas? - Stoney

1 0

Alternative MemberAdaptors
by barry＠python.org 05 Mar '03

05 Mar '03

This message is primary for those of you writing or using alternative MemberAdaptor implementations (e.g. SQL). Yesterday I checked in a working implementation of a member adaptor based on BerkeleyDB. It seems to greatly improve the memory footprint for really huge lists, at the cost of greater administrative overhead (because you have to know how to setup and manage BerkeleyDBs), and potentially slower performance (I haven't benchmarked it; this is just based on my experience with BerkeleyDB in general). I've found a few things during this experience that point to things we ought to improve. I don't have a lot of time right now, but I wanted to put this out there to start the discussion. I'll quickly mention a few things. - I wanted to hook into the BDB transaction (txn) machinery, and I found a convenient hook. I overloaded MailList.Lock() to include a txn begin, MailList.Save() to do a txn commit, and MailList.Unlock() to do a txn abort. This seems to work well as long as aborting after committing is harmless (it is in BDB). I'd like to get feedback from the SQL folks (or other MemberAdaptor developers) on whether we need more explicit transaction support or whether the basically necessary hooks are already there. - To make this work, however, I found I had to change the order of when the extend.py hook gets run. Specifically, I needed it to run /before/ the list is locked in MailList.__init__(), otherwise locking contructors don't hook into the machinery. I want to commit this change but I don't want to break other MemberAdaptors or extend.py hooks. - We really need to optimize the MemberAdaptor API and the implementations that use them. Especially methods that return lists, e.g. getMembers() and friends. Right now, everything has to return a list, but I could do much better by returning iterators, because I can load my iterator up with a BDB cursor. This has the advantage of not requiring the entire member database to be loaded into memory just to iterate over it. Unfortunately, too much of the rest of the code assumes these methods return lists, and while I started to go down the iterator path, I backed out of it because of the complexity. There are other optimizations that would require a bit more thought. E.g. the admin's Membership List page seems to require that the entire member database be iterated over to chunkify and bucketize. Fixing this probably requires both changes to the u/i and changes to the interface. It also makes life more difficult for OldStyleMemberships, although BDBMemberAdaptor can probably be fairly easily elaborated. I'd like to hear from other member adaptor implementations on their thoughts here. - I'd love for any BerkeleyDB experts to review the BDBMemberAdaptor code, especially in some of the choices I've made for creating and opening the environment. I had a lot of practical problems with this part of the code, especially in getting multiple processes to cooperate reasonably. Any BerkeleyDB experts out there? (I'm fairly happy with the schemas, at least for the current MemberAdaptor API). - I'm leaning heavily toward having this stuff in Mailman 2.2 and /not/ porting it to 2.1.x. Too many changes for a micro release, although it makes project management more complicated, especially in merging fixes back into the 2.1.x maintenance branch. Sigh. Okay, I'm out of time for today. Any feedback will be appreciated, even if I can't respond immediately. Also, the BerkeleyDB based member adaptor seems to work, but should be considered experimental. See the BDBMemberAdaptor.py comments for how to hook this up to a mailing list. There is currently no migration tool from classic member adaptors to BDBMemberAdaptors, although I intend to write such a beast and run a few of my personal lists on the code to flesh things out. Enjoy, -Barry

3 2

public archives and email adresses
by Kasper Daniel Hansen 05 Mar '03

05 Mar '03

Hi I've recently created a mailing list with mailman and are quite satisfied. However I have one simple question/request: If I have public archives and a member of the list has a signature in their email reader, this signature is included in the archive. But - at least in my list - it is quite common for signatures to include the posters email adress which therefore are being made accesible on a public webpage. Is it possible to strip messages of the signature before they are being archived? If so - how? /Kasper

2 1