Mailman 3 February 2004 - Mailman-Developers

archiving problem
by Fil 12 Feb '04

12 Feb '04

Hi, I've upgraded to CVS to get the new bounce management, but now it seems that I have a problem : ==> logs/error <== Feb 12 13:03:10 2004 (9879) Uncaught runner exception: [Errno 32] Broken pipe Feb 12 13:03:10 2004 (9879) Traceback (most recent call last): File "/usr/local/mailman/Mailman/Queue/Runner.py", line 110, in _oneloop self._onefile(msg, msgdata) File "/usr/local/mailman/Mailman/Queue/Runner.py", line 160, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/local/mailman/Mailman/Queue/ArchRunner.py", line 73, in _dispose mlist.ArchiveMail(msg) File "/usr/local/mailman/Mailman/Archiver/Archiver.py", line 200, in ArchiveMail self.ExternalArchive(mm_cfg.PUBLIC_EXTERNAL_ARCHIVER, txt) File "/usr/local/mailman/Mailman/Archiver/Archiver.py", line 175, in ExternalArchive status = extarch.close() IOError: [Errno 32] Broken pipe Feb 12 13:03:10 2004 (9879) SHUNTING: 1076587387.1300571+a3796c3908cc5f9d5f668ff6933510045be10e06 What should I do? -- Fil

1 2

[leadership/opensource] invitation to online survey
by Gianluca Bosco 12 Feb '04

12 Feb '04

Dear all, I have just put online a survey addressing the topic of "leadership in the open-source environment". Basically, my objective is to identify the personal conceptions of good leadership that reside in the minds of the contributors, in terms of leaders' _behaviors_ and _characteristics_. What is a good open-source project leader, from the contributor's point of view? To what extent, those personal believes are shared among developers? Can the contributor's national cultural belonging and level of experience in contributing to open-source projects explain such differences in their idea of what a good leader is? I would really appreciate your participation to the survey! Contribution (*completely* anonymous) consists in rating a list of statements that may be used to describe the behaviors of an open-source leader. It will take around ten minutes - there aren't any "time-consuming" open ended questions;) Following, the link to the survey: http://freeonlinesurveys.com/rendersurvey.asp?id=52191 If you are interested, I will not miss to email you a link to the final report, when ready ;) (approx, a couple of months from now) Thank you in advance, and don't hesitate to contact me if you have any questions or comments :) Gianluca Bosco g.bosco(a)GETRIDOFTHISinwind.it Denmark Technical University Department of manufacturing engineering and management

1 0

3.1.4 upgrade problem
by Joel Ebel 11 Feb '04

11 Feb '04

After upgrading to 3.1.4 from 3.1.3 I now have a problem when any post is attempted. Perhaps someone can help me with this. Traceback (most recent call last): File "/usr/local/mailman/scripts/post", line 69, in ? main() File "/usr/local/mailman/scripts/post", line 64, in main tolist=1, _plaintext=1) File "/usr/local/mailman/Mailman/Queue/Switchboard.py", line 133, in enqueue os.fsync(msgfp.fileno()) AttributeError: 'module' object has no attribute 'fsync' 554 5.3.0 unknown mailer error 1 Thanks, Joel

1 0

3.1.4 upgrade problem
by Joel Ebel 11 Feb '04

11 Feb '04

After upgrading to 3.1.4 from 3.1.3 I now have a problem when any post is attempted. Perhaps someone can help me with this. Traceback (most recent call last): File "/usr/local/mailman/scripts/post", line 69, in ? main() File "/usr/local/mailman/scripts/post", line 64, in main tolist=1, _plaintext=1) File "/usr/local/mailman/Mailman/Queue/Switchboard.py", line 133, in enqueue os.fsync(msgfp.fileno()) AttributeError: 'module' object has no attribute 'fsync' 554 5.3.0 unknown mailer error 1 Thanks, Joel

1 0

(no subject)
by Rawfeednews＠aol.com 11 Feb '04

11 Feb '04

Hi, I am having trouble sending e-mail to my mailing list...I created a list and I have been using it for about 6 months, but all of a sudden, when I e-mail a post...it just disappears and doesn't even appear on the moderator's page. Please let me know, Vin www.the-voice.us

1 0

Re: [Mailman-checkins] mailman/templates/en probe.txt, NONE, 1.1.2.1
by Fil 11 Feb '04

11 Feb '04

This change was very much needed. I lost quite a few administrators like this recently :) > --- NEW FILE: probe.txt --- > This is a probe message. You can ignore this message. I have the feeling that these messages are always too long. Most people don't feel easy reading long "automatic" texts, especially if it arrives in a language they don't perfectly master. In this precise case, the message is long, and talks about things most people have never heard of (probes, bounces, disable/re-enable subscription). What I've done on listes.rezo.net is the following (for example, concerning subscription ack): >>>>>>>>>>>>>>>> start file ---------------------------------------------------------- %(welcome)s Your address has been added to the list %(real_name)s@%(host_name)s Thank you. ---------------------------------------------------------- To unsubscribe, you can write to the following address: <%(real_name)s-off@%(host_name)s> >>>>>>>>>>>>>>>> end file What I mean is that the documentation should not be inside the message (well, that's my view of this user interaction problem). If other people feel the same, we could redesign a set of shorter templates for non-geeks. The probe.txt message is of course very difficult to write, especially if it contains a virus attached as a copy... :)

1 0

bin/newlist -o option
by bl＠nk-robert.de 10 Feb '04

10 Feb '04

Hello, I am setting up Mailman 2.1.4-1 on Debian/GNU with postfix-mysql 2.0.16-4. I was googling around and I noticed that I need the newlist -o option to synchronize mailman and /etc/postfix/aliases. but my version of bin/newlist does not support this option. ------------- $/usr/sbin/newlist -h Create a new, unpopulated mailing list. Usage: /usr/sbin/newlist [options] [listname [listadmin-addr [admin-password]]] Options: -l language --language language Make the list's preferred language `language', which must be a two letter language code. -q/--quiet Normally the administrator is notified by email (after a prompt) that their list has been created. This option suppresses the prompt and notification. -h/--help Print this help text and exit. ------------- Well I think you know the out put ;-) For a former version I was hacking /usr/sbin/newlist, but this should not be the way Any ideas? robert

2 1

SQL in MM3 issues
by Kevin McCann 10 Feb '04

10 Feb '04

For those who are interested in working on a MySQL and/or Postgres backend end for Mailman 3, I'd like to get some feedback on *very basic* notions. First, for me, the whole reason I want to see this SQL thing happen is so that I can have the three primary data tables at my "SQL select" disposal so that I can build Neat Things. Those data tables being 1) list configuration data, 2) member data, and 3) message archives. What kind of Neat Things require this, you ask? Well, let's say I wanna build this wonderful tool called "EZ-Groups." It has all sorts of great stuff: list info w/ archives, user profiles, documents, a calendar. You name it. All the stuff I want to have to build my happy communities. I wanna log into my EZ-Groups web site, which is powered by Mailman 3, of course. And once I log in, on the left hand side I want to see all of my groups (lists) listed on the left hand side. I then want to click on one of them and voila!, I see all sorts of info about the list. The purpose, how many members, and, of course, an index of most recent messages. I want to click on a message subject to view the message. I might even want to see profile information about the person who sent that message. If the list is configured as "members can view subscriber list" then I want to see a link which will allow me to see the list of subscribers ( I also get to see it if Im logged in as the list admin). And I want to do this - and much more - all on one site, with a common header and one display area. Basically a one-stop place for me to engage my various communities. Are you still reading this? If so, maybe you've thought about this stuff before. Or you're thinking "this kinda sounds like Yahoogroups." And if you have tried to build something like this before with an MLM that has various bits of data here and there in hard-to-get-at places, you know it's not a walk in the park. As it turns, out my colleagues and I *have* built something like this. We were able to do so with Lyris as the backend, a MS SQL database which contains all of the Lyris data - and I mean all of it - and the ColdFusion scripting language. This set up has allowed me to write some pretty neat Lyris data-accessing apps since 1998. I want to do this same kind of thing with Mailman 3. And so I want, at the very least, to have those three aforementioned tables of data: lists members messages Can anyone think of any reason why we would not want to have these three tables in a SQL-enabled Mailman 3. What other tables might you want to see? Or fields that might not be found in the above three tables? May I suggest that you be creative, think ahead, and don't restrict yourself by notions of what an MLM is in the here-and-now. If we can first agree on tables, maybe we can move forward and work on the core field sets for each one. And this will in turn give us something to chew on at the sprint. Barry does this approach make sense? Also, would it be better to set up a Wiki or another list somewhere for this topic (SQL-enabling Mailman3)? Thanks, Kevin

4 3

Tracking down a permissions bug in attachments
by Andrew Mellinger 09 Feb '04

09 Feb '04

Y'all, I think I may have found a bug with the attachments code and hoped that you guys could give me some input. When trying to save an attachment my installation of mailman provides the following error. +---- Jan 23 07:05:52 2004 (24615) Traceback (most recent call last): File "/usr/pkg/lib/mailman/Mailman/Queue/Runner.py", line 110, in _oneloop self._onefile(msg, msgdata) File "/usr/pkg/lib/mailman/Mailman/Queue/Runner.py", line 160, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/pkg/lib/mailman/Mailman/Queue/ArchRunner.py", line 73, in _dispose mlist.ArchiveMail(msg) File "/usr/pkg/lib/mailman/Mailman/Archiver/Archiver.py", line 208, in ArchiveMail h.processUnixMailbox(f) File "/usr/pkg/lib/mailman/Mailman/Archiver/pipermail.py", line 544, in processUnixMailbox m = mbox.next() File "/usr/pkg/lib/python2.2/mailbox.py", line 34, in next return self.factory(_Subfile(self.fp, start, stop)) File "/usr/pkg/lib/mailman/Mailman/Mailbox.py", line 89, in scrubber return mailbox.scrub(msg) File "/usr/pkg/lib/mailman/Mailman/Mailbox.py", line 109, in scrub return self._scrubber(self._mlist, msg) File "/usr/pkg/lib/mailman/Mailman/Handlers/Scrubber.py", line 219, in process url = save_attachment(mlist, part, dir, filter_html=0) File "/usr/pkg/lib/mailman/Mailman/Handlers/Scrubber.py", line 344, in save_attachment makedirs(fsdir) File "/usr/pkg/lib/mailman/Mailman/Handlers/Scrubber.py", line 336, in makedirs os.path.walk(dir, twiddle, None) File "/usr/pkg/lib/python2.2/posixpath.py", line 279, in walk func(arg, top, names) File "/usr/pkg/lib/mailman/Mailman/Handlers/Scrubber.py", line 335, in twiddle os.chmod(dirname, 02775) OSError: [Errno 1] Operation not permitted: '/var/db/mailman/archives/private/rq-rules/attachments/20040123/72aeb309' +---------- Now, it looks to me like Mailman is trying to set permissions on the newly created directory to 02775. I'm running on NetBSD which doesn't let anyone but the superuser set the 2000 (setuid) bit. I imagine this setting (02775) was done for linux which overloads the setuid bit for as 'set group' on new files. Does this sound like a good assessment? If so, is there a generic way to turn this sort of thing off in a config? (I searched by couldn't find anything.) Isn't this something that should be handled at build time? Thanks for any feedback! -Andrew

2 2

Several big changes slated for 2.1.5 (long)
by Barry Warsaw 09 Feb '04

09 Feb '04

I have some rather big changes ready for MM2.1.5 that I wanted to describe and get feedback from you. While I have this stuff working and ready to be checked in, we will definitely need some beta testing before unleashing on the world. I hope you'll be able to help with that. I think these changes are important enough to put into 2.1 rather than waiting for any future major release. The first big change is the most externally visible one. I believe the current scheme for bounce processing is unusable in today's world of MyDoom sender forgeries, anti-virus front-ends on remote SMTPs and the like. On python.org we've seen many cases where people are getting unexpectedly bounce disabled, even though they receive all legitimate traffic to a mailing list. What's happening? It's simply that, while we have spam and virus defenses in place on python.org, some crap still gets through. Imagine I'm on a busy list and I forward barry(a)python.org through my home ISP, which has a virus and spam detector on that address. Now say that list gets 100 msgs/day and 1% of those messages are false negative spams. The message gets onto the list, but my ISP catches them and rejects them, which triggers a bounce and thus my score's just been increased by 1. I only need one sneaky spam per day to get me bounce disabled, even though most of the mail is legit and gets through. So I've implemented a revised scheme that we've talked about before, based on what I believe ezmlm does. All the bounce parameters are still in effect, however when a member's bounce score reaches the threshold, we now send a specially prepared probe message containing a VERP'd sender with an unguessable token. When we send the probe, the member's bounce score is reset. If the probe bounces, then we disable the member and do the normal reminders. If the probe doesn't bounce the member would stay enabled and their score starts accumulating from zero again. A benefit of this rewrite is that we can include in the probe, the last bouncing message as a sample to the user so they can start to get a clue as to why they're getting bounce scored. This change has prompted an internal rewrite of the pending database. Previously the entire site had a single pending.pck file for all actions requiring confirmation by the user -- held subscription cancellation, subscription, unsub, and change of address confirmations, and bounce re-enable confirmations. This was a problem for several reasons, including that every list had to block on acquiring the lock for this file. Now, each list has its own pending.pck file and while the list lock must be acquired to update this database, at least this doesn't block other lists from doing things. The upgrade script attempts to migrate the single shared pending.pck file to the individual list files, but the conversion is difficult because the associated list is not stored with most of the records in that file. I do my best, but it's possible that some pending actions may get lost. The other big change is a purely internal one, but it may affect the work flow for some admins. I've changed the qfiles file format so that only one file is used per message. Previously we had one file for the message and one file for the metadata. Now, a single pickle file is used with the first object in the pickle being the message object and the second being the metadata dictionary. This approach has several advantages. The code is simpler, there are no race conditions opportunities, we can't possibly have orphaned data files, and probably most importantly we now only need half the inodes we did before. In addition, I've decided to turn on fsync'ing for this new qfile all the time, so storage should be more reliable too. The downside is that I've removed the ability to set a METADATA_FORMAT. We use Python pickles and that's it. I doubt many people have been using (or were even aware of) the alternatives, although I've had the occasional bug report on them so I know that number is non-zero. The other downside for some people is that the behavior of SAVE_MSGS_AS_PICKLES=False will change. When that non-standard setting is used, we'll still write everything to a pickle file, but we'll use text pickles instead of the more efficient (but not human readable) binary pickles. Also, we'll write the message object as a pickled string instead of a pickled object. Again, this will be less efficient because we'll have to parse the message every time it's dequeued, but this option will still allow people to edit queued messages with a normal text editor, albeit less conveniently. I think this trade-off is worth it. The upgrade script will combine any existing qfiles so you won't have to clear your queue when upgrading. To be safe, you /will/ have to stop Mailman, your MTA, and your web server before upgrading (but this was always recommended practice). I intend to commit these changes to CVS within a week and will probably release a 2.1.5 alpha. This will touch a lot of files, but it will hopefully make the system more efficient and usable. Once this is done I hope to have more time to start addressing other bugs and issues in the 2.1 branch. Again, when everything's checked it, please test things out as much as possible, especially if you are using older Python versions. I've tested primarily with Python 2.3.3 but I was careful not to use any feature that isn't supported in Python 2.1.3. I might have missed something though. -Barry

1 0