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.
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
--------------------------------
[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
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
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.
[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
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
[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
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/
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