Mailman 3 December 1998 - Mailman-Developers

[ANNOUNCE] Mailman 1.0b7
by Barry A. Warsaw 06 Jan '99

06 Jan '99

Folks, I've built the tarball for the Mailman 1.0b7 release, however since John appears to be not reading his email during the holiday season, the Web pages at www.list.org have not yet been updated. For now, you can grab the tarball from ftp://ftp.python.org/pub/tmp/mailman-1.0b7.tgz and we'll get the Web site updated ASAP. Below is an excerpt from the DONE file which gives some highlights for this release. My hope is that y'all will bang on this version in the next week or two and, if there are no showstoppers, we can get the full 1.0 release out by mid-January. Given the holiday season, a couple of weeks late isn't so bad! Let me also say that we've got a huge backlog of very good suggestions, contributions, ideas, etc. and on behalf of the other 3 core developers I thank you and encourage you to continue giving feedback. I've spent most of the last 10 days on vacation just trudging through 400-odd messages that I'd accumulated, and I think 1.0b7 fixes most of the really nasty bugs that have been reported up until now. What I haven't done is spend much time adding new features and I don't expect to until after 1.0 final is released. I firmly believe we need to get a stable 1.0 out RRSN, then we can begin to prioritize the new features for 1.1. High on my list is internationalization and an improved Web navigation interface. Longer term, I'm looking at Zope <www.zope.org> as a possible platform for Mailman. I know John, Ken, and Scott all have their priorities too. Big thanks go to those guys, and especially Scott Cotton, for their work on this release. Enjoy, and have a Happy New Year. -Barry -------------------- snip snip -------------------- 1.0b7 - Many, many bug fixes. Some performance improvements for large lists. Some improvements in the Web interfaces. Some security improvements. Improved compatibility with Python 1.5. - bin/convert_list and bin/populate_new_list have been replaced by bin/add_members. - Admins can now get notification on subscriptions and unsubscriptions. Post are now logged. - The username portion of email addresses are now case-preserved for delivery purposes. All other address comparisions are case-insensitive. - New default SMTP_MAX_RCPTS that limits the number of "RCPT TO" SMTP commands that can be given for a single message. Most MTAs have some hard limit. - "Precedence: bulk" header and "List-id:" header are now added to all outgoing messages. The latter is not added if the message already has a "List-id:" header. See RFC 2046 and draft-chandhok-listid-02 for details. - The standard (as of Python 1.5.2) smtplib.py is now used. - The install process now compiles all the .py files in the installation. - Versions of the Mailman papers given at IPC7 and LISA-98 are now included.

2 2

small sec problem / or feuture (?)
by Bencsath Boldizsar 06 Jan '99

06 Jan '99

Hi, I am not list member, but didn't find any bugreport address in the docs of mailman ( please make one.. :) ) So, in 1.0b6 there is a small problem: Pendig messages can be seen by anyone / i didn't checked the privacy options, but it's more logical, that pending messages are only viewable by the admin through the password. check http://www.anything.something/mailman/admindb/<listname> boldi -------------------------------- Bencsath Boldizsar boldi(a)inf.bme.hu boldi(a)rulez.org greetings to mol S.A.I.C. VIP Protection SASSTIXS http://www.inf.bme.hu/~boldi --------------------------------

3 3

Re: [Mailman-Developers] configure not aware of Mailman/pythonlib
by Harald Meland 30 Dec '98

30 Dec '98

[Barry A. Warsaw] > I've just done a manual sync, so please try again. Done. Things sure look better now :) [ In the hope that it might help you debugging, here are the files that were changed by the update: Makefile.in UPGRADING configure configure.in bin/Makefile.in bin/update doc/LISA-98/README doc/LISA-98/published.ps mail/contact_transport ] -- Harald

1 0

configure not aware of Mailman/pythonlib
by Harald Meland 30 Dec '98

30 Dec '98

I just braved upgrading from beta 6 to the current CVS version, and got slightly bruised from the fact that configure doesn't know anything about the Mailman/pyhtonlib directory. I think the patch below fixes this (if you run "aclocal; autoconf" after applying it, of course), but then I'm not very familiar with autoconf, so I could be totally wrong :) Index: configure.in =================================================================== RCS file: /projects/cvsroot/mailman/configure.in,v retrieving revision 1.26 diff -u -r1.26 configure.in --- configure.in 1998/11/17 23:49:12 1.26 +++ configure.in 1998/12/30 18:46:51 @@ -364,7 +364,7 @@ AC_OUTPUT([misc/paths.py Mailman/Defaults.py Mailman/mm_cfg.py.dist src/Makefile misc/Makefile bin/Makefile Mailman/Makefile Mailman/Cgi/Makefile Mailman/Logging/Makefile - Mailman/Archiver/Makefile + Mailman/Archiver/Makefile Mailman/pythonlib/Makefile mail/Makefile templates/Makefile cron/Makefile filters/Makefile scripts/Makefile cron/crontab.in Makefile]) -- Harald

2 1

Problems getting news/mail gateway working (with fixes)
by Steve Phillips 24 Dec '98

24 Dec '98

System: Debian: 2.0 Mailman: 1.0b6 (compiled, not from .deb package) Inn: 1.7.2 (debian package version 1.7.2-4) I found one bug in the Python source and one installation error: I'm trying to set up Mailman on my system to gateway between mail and news. I found I was getting the following error in my syslog when trying to gateway mail to news: ----------------------------------------------------------------------- Dec 23 13:05:00 hodag /USR/SBIN/CRON[12324]: (mailman) CMD (/usr/bin/python /hom e/m/mailman/cron/gate_news) Dec 23 13:09:05 hodag sendmail[12352]: NAA12352: from=<sjp(a)siliconlogic.com>, si ze=671, class=0, pri=30671, nrcpts=1, msgid=<36813FAF.710DD6C6(a)siliconlogic.com> , proto=ESMTP, relay=relay.siliconlogic.com [207.67.84.2] Dec 23 13:09:05 hodag sendmail[12353]: NAA12353: clone NAA12352, owner=test-admi n Dec 23 13:09:07 hodag nnrpd[12358]: hodag.buzzsaw.net connect Dec 23 13:09:07 hodag nnrpd[12358]: hodag.buzzsaw.net post failed Duplicate "Sen der" header Dec 23 13:09:07 hodag nnrpd[12358]: hodag.buzzsaw.net exit articles 0 groups 0 Dec 23 13:09:07 hodag nnrpd[12358]: hodag.buzzsaw.net posts received 0 rejected 1 Dec 23 13:09:07 hodag nnrpd[12358]: hodag.buzzsaw.net times user 0.010 system 0. 010 elapsed 0.131 ----------------------------------------------------------------------- Looks like it failed because the header that innd got was bad. Investigation revealed this bit of code from GatewayManager.py: subj = msg.getheader('subject') if not subj: msg.SetHeader('Subject', '%s(no subject)' % prefix) if self.reply_goes_to_list: del msg['reply-to'] msg.headers.append('Reply-To: %s\n' % self.GetListEmail()) msg.headers.append('Sender: %s\n' % self.GetAdminEmail()) msg.headers.append('Errors-To: %s\n' % self.GetAdminEmail()) msg.headers.append('X-BeenThere: %s\n' % self.GetListEmail()) msg.headers.append('Newsgroups: %s\n' % self.linked_newsgroup) Looks like a new Sender: line is getting added, but the original one is not removed. I commented out this line and then things started working. As for news to mail: I got the following error for that: ----------------------------------------------------------------------- Received: (from root@localhost) by hodag.buzzsaw.net (8.8.8/8.8.8/Debian/GNU) id PAA13832 for mailman; Wed, 23 Dec 1998 15:30:05 -0600 Date: Wed, 23 Dec 1998 15:30:05 -0600 Message-Id: <199812232130.PAA13832(a)hodag.buzzsaw.net> From: root (Cron Daemon) To: mailman Subject: Cron <mailman@hodag> /usr/bin/python /home/m/mailman/cron/gate_news X-Cron-Env: <SHELL=/bin/sh> X-Cron-Env: <HOME=/home/m/mailman> X-Cron-Env: <PATH=/usr/bin:/bin> X-Cron-Env: <LOGNAME=mailman> sh: /home/m/mailman/scripts/post: Permission denied ----------------------------------------------------------------------- Installed permisions on "post" were: -rw-r--r-- 1 root mailman 2832 Dec 23 14:14 post I did chmod 755 on post and then things started working correctly.

2 1

Re: [Mailman-Developers] The bulk issue
by Harald Meland 23 Dec '98

23 Dec '98

[Ken Manheimer] > More importantly, after reviewing the vacation man page, i realized > that the precedence: bulk header would be redundant for mailing list > traffic, since most of the kinds of things that respect it also > refrain from responding to messages that do not have the recipient's > address explicitly mentioned among the destination addresses, which > is inherently the case for maillist traffic - so the precedence: > bulk is unnecessary. I'd say inserting a "Precedence: list" header is a good thing anyway. Consider the case of a vacation program not knowing which addresses maps to which mail users -- such a vacation program (which is not at all uncommon) would have (very nearly) no idea whether the address in the To: header is a mailing list address or some strange alias pointing to the mail user it is trying to do it's thing for. Giving such a vacation program an additional header to base it's judgement on is IMHO a good thing. I have no idea where, or even if, "Precedence: list" is standardized in any way, but I think that thath is what majordomo is inserting. Being compatible with majordomo when it doesn't cost us anything is also, IMHO, a good thing. The only reason I see for _not_ adding any Precedence: header, is that Mailman-delivered messages have half a truckload of headers as it is. But that, IMHO, isn't really a strong argument -- as long as all the headers are there for some good reason, they _should_ be in there. Just my ¤.02, -- Harald

3 3

smtplib.py
by Barry A. Warsaw 22 Dec '98

22 Dec '98

I think I've integrated the Python 1.5.2 smtplib.py into Mailman for 1.0b7. I'm no smtp expert so I'd like someone with CVS access to double check what I've done. Here's a summary. I am removing Mailman/smtplib.py, and creating a new package directory inside Mailman called Mailman/pythonlib. This package will contain newer versions of standard Python libraries, that may not exist (or be out of date) out in the field. E.g. this directory now contains smtplib.py from nearly-Python-1.5.2. If we ever have version skew down the road, this may contain other copies of such libraries. When require Python 1.5.2 or better, we can remove Mailman/pythonlib/smtplib.py Now, I've tracked down every reference to smtplib.py and the only useful one seems to be Mailman/Utils.py. I've removed all other imports of smtplib from places where they were not used. Then I modified TrySMTPDelivery() in Utils.py to get the correct smtplib (standard Python one if the attribute smptlib.SMTP.ehlo exists, otherwise, it imports the one out of the Mailman.pythonlib package). Finally, I rewrote the code in this function to call the standard interface, which seems very simple: essentially call smtplib.SMTP(...).sendmail(). In my limited testing, this appears to work just fine. I plan to check all this stuff in in a few moments. Please someone double check me. If I've messed up badly, I'll revert. Also, I plan to move bin/update_to_10b6 to bin/update. We'll just keep adding new update procedures to this script as new versions are released. I plan to add removal of $prefix/Mailman/smtplib.py{,c}. -Barry

1 0

Re: [Mailman-Developers] The bulk issue
by Harald Meland 20 Dec '98

20 Dec '98

[Barry A. Warsaw] > >>>>> "HM" == Harald Meland <Harald.Meland(a)usit.uio.no> writes: > > HM> I have no idea where, or even if, "Precedence: list" is > HM> standardized in any way, but I think that thath is what > HM> majordomo is inserting. Being compatible with majordomo when > HM> it doesn't cost us anything is also, IMHO, a good thing. > > As far as I can tell, it is not documented anywhere; not even in the > update to RFC 2076. Sorry, my mistake. I should have said "Due to the behaviour I am seeing on some of the majordomo lists I am on, I think that majordomo inserts `Precedence: list' headers." Now that I have actually done some grepping of the majordomo source, I can't find anything in majordomo 1.94.4 which should cause the precedence header to default to anything but "bulk". Thus, I agree that inserting "Precedence: list" as a default seems inappropriate. However, I believe that not inserting any Precedence: header *at*all* will cause trouble. My example (the vacation program which doesn't know the mapping between local users and local addresses) was meant to show that inserting *a* Precedence: header would be useful. > I'll see if I can search around in Majordomo to see what they do, > but if anybody else can verify this, it would be helpful. I don't know majordomo very intimately (neither do I want to get to know it all that much better :), so getting a second opinion would be wise :) Still, config_parse.pl says: # provide list of known keys. If value is '', then the key is undefined # I.e. the action is just as though there was no keyword found. # otherwise the value is the default value for the keyword. # if the value starts with #!, the rest of the value is eval'ed %known_keys = ( [...] 'precedence', 'bulk', # Set/install precendence header implying that "bulk" is the default value for the "precedence" configuration setting. -- Harald

1 0

Deliverer.py
by Greg Stein 19 Dec '98

19 Dec '98

Two items that I noticed in Deliverer.py: 1) it writes to stderr, rather than logging 2) the writes do not have a final newline Cheers, -g -- Greg Stein, http://www.lyra.org/

4 6

The bulk issue
by Ken Manheimer 19 Dec '98

19 Dec '98

Can anyone say why we are not putting "Precedence: bulk" on maillist traffic passed by mailman? I seem to recall raising the issue, and having objections, but i'm not recalling the objections, and my yearning to have vacation programs behave like we want (ignoring the messages) is still increasing. So i propose again that we inject our own precedence header iff one is not already there... Ken ---------- Forwarded message ---------- Date: Thu, 3 Dec 1998 14:34:08 -0800 (PST) From: via the vacation program <murdock(a)psych.ucsb.edu> Subject: away from my mail I will be out of the office until Monday December 14. Your email regarding "Re: [Mailman-Users] Compilation problems" will be read when I return. Larry Murdock

4 5