[RELEASED] Mailman 2.1 alpha 3
I've finally decided to put a fork in it and release the third, and hopefully last alpha in the Mailman 2.1 series. If you want to see a description of all the new stuff, please see
http://sourceforge.net/project/shownotes.php?release_id=58074There's quite a lot there!
Everything should be up on SourceForge now, with updates to www.list.org hopefully tomorrow some time. See also
http://mailman.sf.net/MM21/for updated pages about Mailman 2.1.
Note that you no longer need to install the mimelib package. This has been replaced by the email package, which comes with Python 2.2b1, or for Python 2.1.1 or 2.0.1, you'll need to install email-0.93 which is available in the misc/ directory. See the INSTALL file for details.
Below is an excerpt from the NEWS file for all the changes since 2.1 alpha 2. I'm hoping that this will be the last alpha release. That means there's one more release in which we have an opportunity for new features, so I suggest that you grab 2.1a3 and give it a good workout (in a non-production environment <wink>). If there are glaring things missing, as always, let me know.
Please, all discussion about 2.1 alpha should be conducted on the mailman-developers@python.org mailing list.
I will be creating some test lists on python.org an you'll be able to subscribe to them to try things out. I'd like to have a short cycle for alpha3->beta1, with bug fixes only once beta1 comes out.
Language translators: I've updated the langpack on SourceForge with the latest catalogs and templates. I've also uploaded the latest README-I18N.en file if you'd like to contribute new languages. If you've been holding off contributing new language files, please consider finishing them off so that I can integrate them in time for beta1.
Enjoy, -Barry
-------------------- snip snip -------------------- 2.1 alpha 3 (22-Oct-2001)
- Realname support
o Mailman now tracks a member's Real Name in addition to their
email address.
o List members can now supply their Real Names when
subscribing via the web. Their Real Names are parsed from
any thru-email subscriptions.
o Members can change their Real Names on their options page,
and admins can change members' Real Names on the membership
pages. Mass subscribing accepts "email@dom.ain (Real Name)"
entries, for both in-text-box and file-upload mass
subscriptions.
- Filtering and Privacy
o Reply-To: munging has been enhanced to allow a wider range
of list policies. You can now pre-strip any Reply-To:
headers before adding list-specific ones (i.e. you can
override or extend existing Reply-To: headers). If
stripping, the old headers are no longer saved on
X-Reply-To:
o New sender moderation rules. The old `posters',
`member_only_posting', `moderated' and `forbidden_posters'
options have been removed in favor of a new moderation
scheme. Each member has a personal moderation bit, and
non-member postings can be automatically accepted, held for
approval, rejected (bounced) or discarded.
o When membership rosters are private, responses to
subscription (and other) requests are made more generic so
that these processes can't be covertly mined for hidden
addresses. If a subscription request comes in for a user
who is already subscribed, the user is notified of potential
membership mining.
o When a held message is approved via the admindb page, an
X-Moderated: header is added to the message.
o List admins can now set an unsubscribe policy which requires
them to approve of member unsubscriptions.
- Web U/I
o All web confirmations now require a two-click procedure,
where the first click gives them a page that allows them to
confirm or cancel their subscription. It is bad form for an
email click (HTTP GET) to have side effects.
o Lots of improvements for clarity.
o The Privacy category has grown three subcategories.
o The General options page as a number of subsection headers.
o The Passwords and Languages categories are now on separate
admin pages.
o The admin subcategories are now formated as two columns in
the top and bottom legends.
o When creating a list through the web, you can now specify
the initial list of supported languages.
o The U/I for unsubscribing a member on the admin's membership
page should be more intuitive now.
o There is now a separate configuration option for whether the
goodbye_msg is sent when a member is unsubscribed.
- Performance
o misc/mailman is a Unix init script, appropriate for
/etc/init.d, and containing chkconfig hooks for systems that
support it.
o bin/mailmanctl has been rewritten; the `restart' command
actually works now. It now also accepts -s, -q, and -u
options.
o bin/qrunner has been rewritten too; it can serve the role of
the old cron/qrunner script for those who want classic
cron-invoked mail delivery.
o Internally, messages are now stored in the qfiles directory
primarily as pickles. List configuration databases are now
stored as pickles too (i.e. config.pck). bin/dumpdb knows
how to display both pickles and marshals.
- Mail delivery
o If a user's message is held for approval, they are sent a
notification message containing a confirmation cookie. They
can use this confirmation cookie to cancel their own
postings (if they haven't already been approved).
o When held messages are forwarded to an explicit address
using the admindb page, it is done so in a message/rfc822
encapsulation.
o When a message is first held for approval, the notification
sent to the list admin is a 3-part multipart/mixed. The
first part holds the notification message, the second part
hold the original message, and the third part hold a cookie
confirmation message, to which the admin can respond to
approve or discard the message via email.
o In the mail->news gateway, you can define mail headers that
must be modified or deleted before the message can be posted
to the nntp server.
o The list admin can send an immediate urgent message to the
entire list membership, bypassing digest delivery. This is
done by adding an Urgent: header with the list password.
Urgent messages with an invalid password are rejected.
o Lists can now optionally personalize email messages, if the
site admin allows it. Personalized messages mean that the
To: header includes the recipient's address instead of the
list's address, and header and footer messages can contain
user-specific information. Note that only regular
deliveries can currently be personalized.
o Message that come from Usenet but that have broken MIME
boundaries are ignored.
o If the site administrator agrees, list owners have the
ability to disable RFC 2369 List-* headers.
- Building/testing/configuration
o mimelib is no longer required, but you must install the
email package (see the tarball in the misc directory).
o An (as yet) incomplete test suite has been added. Don't try
running it in a production environment!
o Better virtual host support by adding a mapping from the
host name given in cgi's HTTP_HOST/SERVER_NAME variable to
the email host used in list addresses. (E.g. www.python.org
maps to @python.org).
o Specifying urls to external public archivers is more
flexible.
o The filters/ subdirectory has been removed.
o There is now a `site list' which is a mailing list that must
be created first, and from which all password reminders
appear to come from. It is recommended that this list be
called "mailman@your.site".
o bin/move_list is no longer necessary (see the FAQ for
detailed instructions on renaming a list).
o A new script bin/fix_url.py can be used with bin/withlist to
change a list's web_page_url configuration variable (since
it is no longer modifiable through the web).
- Internationalization
o Support for German, Hungarian, Italian, Japanese, and
Norwegian have been added.
- Miscellaneous
o Lots of new bounce detectors. Bounce detectors can now
discard temporary bounce messages by returning a special
Stop value.
o bin/withlist now sports a -q/--quiet flag.
o bin/add_members has a new -a/--admin-notify flag which can
be used to inhibit list owner notification for each
subscription.
- Membership Adaptors
o Internally, mailing list memberships are accessed through a
MemberAdaptor interface. This would allow for integrating
membership databases with external sources (e.g. Zope or
LDAP), although the only MemberAdaptor currently implemented
is a "classic" adaptor which stores the membership
information on the MailList object.
o There's a new pipeline handler module called FileRecips.py
which could be used to get all regular delivery mailing list
recipients from a Sendmail-style :include: file (see List
Extensibility bullet below).
This work was sponsored by Control.com
- List Extensibility
o A framework has been added which can be used to specialize
and extend specific mailing lists. If there is a file
called lists/<yourlist>/extend.py, it is execfile()'d after
the MailList object is instantiated. The file should
contain a function extend() which will be called with the
MailList instance. This function can do all sorts of deep
things, like modify the handler pipeline just for this list,
or even strip out particular admin GUI elements (see below).
o All the admin page GUI elements are now separate
components. This provides greater flexibility for list
customization. Also, each GUI element will be given an
opportunity to handle admin CGI form data.
This work was sponsored by Control.com
- Topic Filters
o A new feature has been added called "Topic Filters". A list
administrator can create topics, which are essentially
regular expression matches against Subject: and Keyword:
headers (including such pseudo-headers if they appear in the
first few lines of the body of a message).
List members can then `subscribe' to various topics, which
allows them to filter out any messages that don't match a
topic, or to filter out any message that does match a
topic. This can be useful for high volume lists where not
everyone will be interested in every message.
This work was sponsored by Control.com
On 10/21/01 11:17 PM, "Barry A. Warsaw" <barry@zope.com> wrote:
http://sourceforge.net/project/shownotes.php?release_id=58074
(clap clap clap clap)
and admins can change members' Real Names on the membership pages. Mass subscribing accepts "email@dom.ain (Real Name)"
You should also accept
Real Name <email@dom.ain>Since that's the other common (perhaps more common) format.
o The list admin can send an immediate urgent message to the entire list membership, bypassing digest delivery. This is done by adding an Urgent: header with the list password. Urgent messages with an invalid password are rejected.
Is the Urgent: header stripped as it passes through Mailman? What happens when a regular user tries to put an Urgent: header on a message as a non-admin?
o There is now a `site list' which is a mailing list that must be created first, and from which all password reminders appear to come from. It is recommended that this list be called "mailman@your.site".
Is there a plan to set up a bounce returned to mailman@your.site to be considered a global bounce and that user is unsubbed from all lists? Right now, mailman effectively throws away bounces from the password reminders, which can be used very effectively to keep stuff clean.
- Membership Adaptors o Internally, mailing list memberships are accessed through a MemberAdaptor interface. This would allow for integrating membership databases with external sources (e.g. Zope or LDAP),
Given that, if someone wants to write a fully external authenticator, is it possible to completely disable mailman's interface for a given list (or all lists?) Including things like monthly password reminders?
I guess what I'm suggesting is Mailman as a slave to a non-attached membership system -- can we really detach it cleanly so it's just a delivery system without rough edges or hacking? Down to the external membership system in headers and footers?
This work was sponsored by Control.com
(clap clap clap clap)
"CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:
>> http://sourceforge.net/project/shownotes.php?release_id=58074
CVR> (clap clap clap clap)Thanks!
>> and admins can change members' Real Names on the membership
>> pages. Mass subscribing accepts "email@dom.ain (Real Name)"
CVR> You should also accept
CVR> Real Name <email@dom.ain>Yup, sorry, it already does. I've updated the NEWS file (for the next release at least).
>> o The list admin can send an immediate urgent message to the
>> entire list membership, bypassing digest delivery. This is
>> done by adding an Urgent: header with the list password.
>> Urgent messages with an invalid password are rejected.
CVR> Is the Urgent: header stripped as it passes through Mailman?
CVR> What happens when a regular user tries to put an Urgent:
CVR> header on a message as a non-admin?Just like an Approved: header, it's always stripped because it contains a password.
Regardless of who sends it, if the Urgent: header's value doesn't match the list admin or list moderator's password, the message is bounced back to the sender.
>> o There is now a `site list' which is a mailing list that must
>> be created first, and from which all password reminders appear
>> to come from. It is recommended that this list be called
>> "mailman@your.site".
CVR> Is there a plan to set up a bounce returned to
CVR> mailman@your.site to be considered a global bounce and that
CVR> user is unsubbed from all lists? Right now, mailman
CVR> effectively throws away bounces from the password reminders,
CVR> which can be used very effectively to keep stuff clean.Yes, there are plans ;). Whether I actually get to it or not we'll see.
>> - Membership Adaptors o Internally, mailing list memberships
>> are accessed through a MemberAdaptor interface. This would
>> allow for integrating membership databases with external
>> sources (e.g. Zope or LDAP),
CVR> Given that, if someone wants to write a fully external
CVR> authenticator, is it possible to completely disable mailman's
CVR> interface for a given list (or all lists?) Including things
CVR> like monthly password reminders?
CVR> I guess what I'm suggesting is Mailman as a slave to a
CVR> non-attached membership system -- can we really detach it
CVR> cleanly so it's just a delivery system without rough edges or
CVR> hacking? Down to the external membership system in headers
CVR> and footers?Hmm, let me try to untangle a couple of issues.
First, this adaptor API is only for membership-related information. It doesn't cover other list-related data, such as "what's the subscription policy for this list?". I want to do that eventually, but not for 2.1.
But the membership API is complete, in that you can ask for a member's real name, their password, their case-preserved email address, their option flags (do they get MIME digests?), their preferred language, etc. It covers adding new members and removing old members.
This means that if you supply a different backend implementation for the API, it's all or nothing: you're responsible for the entire API and managing all the member-related data.
So, when Mailman has to authenticate a user for access to their options page, it uses the API, passing in the email address and the response and it should receive a boolean specifying whether the username/passwords matched.
One other thing that Control.com sponsored, but which I forgot to add to the NEWS file, was an API for an external process to post messages to a list, and to specify the explicit list of recipients in the posting interaction. What this means is that you could create a list, say "employees@dom.ain". Then when you want to post a message to this list, you simply create the message, and determine what the explicit list of recipients is, then send both to the posting code. With the list-extension mechanism, you could also completely defeat the U/I (I think) so that Mailman would indeed act as a posting slave.
>> This work was sponsored by Control.com
CVR> (clap clap clap clap)Indeed!
-Barry
On 10/22/01 9:39 AM, "Barry A. Warsaw" <barry@zope.com> wrote:
CVR> Is the Urgent: header stripped as it passes through Mailman? CVR> What happens when a regular user tries to put an Urgent: CVR> header on a message as a non-admin?
Just like an Approved: header, it's always stripped because it contains a password.
Should these be sent to the admin as well as a possible security breach attempt?
Hmm, let me try to untangle a couple of issues.
First, this adaptor API is only for membership-related information.
I'm actually thinking of moving the membership data completely out of Mailman and having mailman act as a slave to an outside system.
Two reasons:
think of a corporate list server, where subscriber lists are created based on organization charts and aren't under the control of the list server completely.
think of an integrated community, where you want a single subscriber interface, but multiple systems, including (but not limited to) a mail list system.
This means that if you supply a different backend implementation for the API, it's all or nothing: you're responsible for the entire API and managing all the member-related data.
Okay, that's where I'm headed. Except I want to go a little further, which is turn off mailman's interface completely, hopefully on a per-list basis. You could, I suppose, make the list private on the mailman side, but there are still issues, such as header/footer data, etc...
One other thing that Control.com sponsored, but which I forgot to add to the NEWS file, was an API for an external process to post messages to a list, and to specify the explicit list of recipients in the posting interaction. What this means is that you could create a list, say "employees@dom.ain". Then when you want to post a message to this list, you simply create the message, and determine what the explicit list of recipients is, then send both to the posting code. With the list-extension mechanism, you could also completely defeat the U/I (I think) so that Mailman would indeed act as a posting slave.
Okay, neat. That seems pretty close to what I'm thinking. Close enough for government work, at least. So you could use extend() to gut mailman's interface, and then write an external that would, say, look thing up out of an LDAP that interfaces to the corprate database...
On Mon, 22 Oct 2001, Chuq Von Rospach wrote:
I'm actually thinking of moving the membership data completely out of Mailman and having mailman act as a slave to an outside system.
- think of an integrated community, where you want a single subscriber interface, but multiple systems, including (but not limited to) a mail list system.
I'm going to be building this very thing--we've got an incredibly detailed system for orders/content management/etc, and what mailing lists the individuals are subscribed to should be manageable from inside that system. Really what that means is that I want the functionality of Mailman, but I want the database to be the mysql one that the other system uses.
I won't be able to get started on this for another month or so, but knowing that someone has thought about it gives me warm fuzzies. Any pitfalls I should be aware of?
Dale Newfield <Dale@Newfield.org>
"My country, right or wrong" is not a cogent argument. It is one step away from "I was only following orders."
On 10/22/01 10:11 AM, "Dale Newfield" <Dale@Newfield.org> wrote:
I won't be able to get started on this for another month or so, but knowing that someone has thought about it gives me warm fuzzies. Any pitfalls I should be aware of?
It was something I put a fair amount of energy into before I started my sabbatical...
You might look at
<http://www.chuqui.com/cgi-bin/mwf/topic_show.pl?tid=74>
<http://www.chuqui.com/cgi-bin/mwf/topic_show.pl?tid=51>
<http://www.chuqui.com/cgi-bin/mwf/topic_show.pl?tid=82>
For some history of my stuff.
(if you're trying to figure out what the heck I mean by "my sabbatical", look here: <http://www.chuqui.com/cgi-bin/mwf/topic_show.pl?tid=103>)
I basically have three long-term 'things' I'm looking at:
an internal list server, currently a custom perl system, that handles all of Apple's internal groups. The management of those groups is fully external to the system. The current system downloads a data dump from the corporate database every couple of hours and does nasty things to it, turning it into a huge sendmail alias file. A future generation will probably replace that with a real-time LDAP interface. I'd really like to avoid writing the whole beast, and add things like digest capability.
taking all my apple list stuff, and moving subscription management into a central access point for all things Apple. Which doesn't exist yet, but the first pieces are there. I'd really like it so that there's a single place to manage everything you do in your on-line relationship with Apple, not zillions of different forms, signups, accounts, passwords and "if you're looking for *this*, go to *that* web site, not here" notices.
and in my non-apple life, I want to build something similar to (2), but for my own uses. If I decide to return from sabbatical. Or maybe grab an existing thing like php-nuke, and wedge mailman onto the side. But it's really clear (to me) that this stuff all has to get integrated down the road, and giving a user site-wide, consistent administration is a key usability issue -- and there's more to life than mail lists. Tools that don't integrate, are going to find themselves marginalized or replaced.
All IMHO (or actually, IMNSHO).
"CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:
CVR> But it's really clear (to me) that this stuff all has to get
CVR> integrated down the road, and giving a user site-wide,
CVR> consistent administration is a key usability issue -- and
CVR> there's more to life than mail lists. Tools that don't
CVR> integrate, are going to find themselves marginalized or
CVR> replaced.
CVR> All IMHO (or actually, IMNSHO).FWIW, I completely agree.
-Barry
"CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:
Me> Just like an Approved: header, it's always stripped because it
Me> contains a password.
CVR> Should these be sent to the admin as well as a possible
CVR> security breach attempt?I thought about that, but doubt it's worth it. Certainly it could be added with little effort.
CVR> Okay, neat. That seems pretty close to what I'm
CVR> thinking. Close enough for government work, at least. So you
CVR> could use extend() to gut mailman's interface, and then write
CVR> an external that would, say, look thing up out of an LDAP
CVR> that interfaces to the corprate database...Essentially yes. I did an experiment where a list was getting its membership out of a file via FileRecips.py, and I wanted to disable the membership screens (in fact the whole membership item in the admin menu). It was a little hacky, but it worked.
One thing though: while I /think/ the membership api is nicely separated and can be easily replaced, other list configuration variables are not. So you'll still see lots of direct attribute access on MailList objects. Meaning it's much tougher to divert non-membership data to an external source.
That won't change for MM2.1, but it'll likely be the bulk of the work for subsequent versions. In fact, some of the developments in Python 2.2 may make that a whole lot easier. I'm still targetting just Python 2.0 for MM2.1, but there's a possibility we'll up that to Py2.2 for later Mailman releases, especially if it makes stuff like this easy.
-Barry
- (Barry A. Warsaw)
| One thing though: while I /think/ the membership api is nicely | separated and can be easily replaced, other list configuration | variables are not. So you'll still see lots of direct attribute | access on MailList objects. Meaning it's much tougher to divert | non-membership data to an external source.
Why is that, if you replace the normal MailList objects with some opaque objects using __getattr__ and __setattr__ for getting the data out of somewhere else?
--
Tollef Fog Heen Axiom #1: You Can't Win
"TFH" == Tollef Fog Heen <tollef@add.no> writes:
TFH> * (Barry A. Warsaw)
BAW> One thing though: while I /think/ the membership api is
BAW> nicely separated and can be easily replaced, other list
BAW> configuration variables are not. So you'll still see lots of
BAW> direct attribute access on MailList objects. Meaning it's
BAW> much tougher to divert non-membership data to an external
BAW> source.
TFH> Why is that, if you replace the normal MailList objects with
TFH> some opaque objects using __getattr__ and __setattr__ for
TFH> getting the data out of somewhere else?MM2.1 already uses __getattr__() as a hamfisted way of implementing the gui (web) components, so overriding these in a MailList derived class would be a little tricky.
Python 2.2 provides some hope here, with its descriptors and properties, and this is one of the things I'd like to explore for MM-the-next-generation-after-2.1.
Cheers, -Barry
Barry,
We're starting to get inundated with FAQs, especially on the -users list. How about setting up one of the FAQ engines beside the Mailman ZWiki so that we can throw content there and just refer to it?
-- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
"JCL" == J C Lawrence <claw@kanga.nu> writes:
JCL> We're starting to get inundated with FAQs, especially on the
JCL> -users list. How about setting up one of the FAQ engines
JCL> beside the Mailman ZWiki so that we can throw content there
JCL> and just refer to it?Excellent idea. I'll try to set one up on zope.org tomorrow if possible. Otherwise I'll set one up on python.org like the Python FAQ wizard. Stay tuned...
-Barry
participants (5)
-
barry＠zope.com -
Chuq Von Rospach -
Dale Newfield -
J C Lawrence -
Tollef Fog Heen