I am very happy to announce the release of the seventh alpha for Mailman 3.0,
code named "Mission". Here are some of the highlights of a release with lots
of new stuff (a more detailed NEWS.txt file excerpt is below).
* Significant improvements to the subscription model. Users can now subscribe
to mailing lists with either an explicit address or a "preferred" address.
When a user changes her preferred address, all of her subscriptions
automatically track this change. All this and more have also all been
exposed to the REST API.
* New rules for member and non-member moderation. This effectively ports and
updates Mailman 2's moderation rules to the Mailman 3 framework.
* Support for SMTP AUTH added.
* The default password encryption scheme can be defined in the configuration
file, and all passwords are by default encrypted (using SSHA1).
* 'bin/mailman status' command added to provide command line status of the
master queue runner process.
* 'bin/mailman info' now prints the REST API root url and credentials.
* Basic Auth support for the REST API was added. (thanks Jimmy Bergman)
* Python 2.7 is supported.
I'm really excited about this release because it will provide a great baseline
for our Google Summer of Code students. If you've been putting off taking a
look at Mailman 3, I encourage you to download it and play with it. My goal
is for a final release on 11.11.11 so there will not be too many more alphas.
Now is the best time to influence our design decisions.
The tarball can be downloaded from Launchpad or the Cheeseshop:
The full documentation is also online:
3.0 alpha 7 -- "Mission"
* Significant updates to the subscription model. Members can now subscribe
with a preferred address, and changes to that will be immediately reflected
in mailing list subscriptions. Users who subscribe with an explicit
address can easily change to a different address, as long as that address
is verified. (LP: #643949)
* IUsers and IMembers are now assigned a unique, random, immutable id.
* IUsers now have created_on and .preferred_address properties.
* IMembers now have a .user attribute for easy access to the subscribed user.
* When created with add_member(), passwords are always stored encrypted.
* In all interfaces, "email" refers to the textual email address while
"address" refers to the `IAddress` object.
* mailman.chains.base.Chain no longer self registers.
* New member and nonmember moderation rules and chains. This effectively
ports moderation rules from Mailman 2 and replaces attributes such as
member_moderation_action, default_member_moderation, and
generic_nonmember_action. Now, nonmembers exist as subscriptions on a
mailing list and members have a moderation_action attribute which describes
the disposition for postings from that address.
* Member.is_moderated was removed because of the above change.
* default_member_action and default_nonmember_action were added to mailing
* All sender addresses are registered (unverified) with the user manager by
the incoming queue runner. This way, nonmember moderation rules will
always have an IAddress that they can subscribe to the list (as
* Support for SMTP AUTH added via smtp_user and smtp_pass configuration
variables in the [mta] section. (LP: #490044)
* IEmailValidator interface for pluggable validation of email addresses.
* .subscribe() is moved from the IAddress to the IMailingList
* IAddresses get their registered_on attribute set when the object is created.
* [devmode] section gets a new 'testing' variable.
* Added password_scheme and password_length settings for defining the
default password encryption scheme.
* creator_pw_file and site_pw_file are removed.
* 'bin/mailman start' does a better job of producing an error when Mailman is
* 'bin/mailman status' added for providing command line status on the master
queue runner watcher process.
* 'bin/mailman info' now prints the REST root url and credentials.
* mmsitepass removed; there is no more site password.
* Add Basic Auth support for REST API security. (Jimmy Bergman)
* Include the fqdn_listname and email address in the member JSON
* Added reply_goes_to_list, send_welcome_msg, welcome_msg,
default_member_moderation to the mailing list's writable attributes in the
REST service. (Jimmy Bergman)
* Expose the new membership model to the REST API. Canonical member resource
URLs are now much shorter and live in their own top-level namespace instead
of within the mailing list's namespace.
* /addresses/<email>/memberships gets all the memberships for a given email
* /users is a new top-level URL under which user information can be
accessed. Posting to this creates new users.
* Users can subscribe to mailing lists through the REST API.
* Domains can be deleted via the REST API.
* PUT and PATCH to a list configuration now returns a 204 (No Content).
* Support Python 2.7. (LP: #667472)
* Disable site-packages in buildout.cfg because of LP: #659231.
* Don't include eggs/ or parts/ in the source tarball. (LP: #656946)
* flufl.lock is now required instead of locknix.
* Typo in scan_message(). (LP: #645897)
* Typo in add_member(). (LP: #710182) (Florian Fuchs)
* Re-enable bounce detectors. (LP: #756943)
* Clean up many pyflakes problems; ditching pylint.
For many years, Atlassian has provided the GNU Mailman project with free (as
in beer) wiki hosting on their proprietary platform. This has included a free
license, free hosting, and free support. We are very grateful to them for
this, as our wiki contains lots of useful information that help you, the
members of our Mailman community.
The current wiki was offered to us at a time when we didn't really have any
other options. However, GNU Mailman is free software and a GNU project, so it
is not appropriate for us to be hosting our wiki on non-free software. We
have offers for hosting a new wiki on Moin <http://moinmo.in/> a very
excellent free wiki engine written in Python.
The major hurdle is actually finding the resources to do a high-fidelity
conversion from the current wiki to Moin, retaining as much of the current
feature set, layout, and history as possible during the migration. None of
the core Mailman developers has time to do this, though we will support the
effort. We tried, but were unable to get a slot in this year's Google Summer
of Code for the conversion work.
Now the FSF has put out a call for volunteers:
If you'd like to help GNU Mailman in this way, please contact the FSF at
We will provide as full a data dump from the current wiki as possible, and
guidance for requirements, etc., and the Moin developers have graciously made
themselves available to help with the technical details. Your conversion work
will of course be free software itself, so it will help Moin and other free
software projects wanting to do similar conversions. I hope you'll consider
help us out with this.
I hope you'll all join me in welcoming our new Google Summer of Code
* Benedict Stein (benste on IRC) will be working to complete the GSoC
work Anna did last summer on the django-based web UI for Mailman 3.0.
* Drew Rodman will be converting pipermail to use SQL (rather than
pickles) for storing data and creating an upgrade script to help users
migrate their archives to the new format. He's even hoping to get
Stable URLs working by the end of the summer!
* Dushyant Bansal (dushyant on IRC) will be working on the interface of
the archives, integrating work from Yian and Priya's GSoC projects last
summer and getting it all ready to go for Mailman 3.
I'm really excited to have all these great projects and great students!
While the students do have a set of official mentors (Barry, Florian,
Anna and me), you're all encouraged to help out throughout the summer.
The end goal is to have some fully integrated awesomeness, so don't be
shy if you've got questions, suggestions, etc.
If you've been lurking here wondering how to get involved with Mailman
3, now might be a great time: we've got mentors who've already set aside
time to be involved this summer, and we've got students who could
benefit from having more people involved in development effort over the
next few months. For example, we discovered while our students were
writing patches that we don't have a great description of the Mailman 3
install process, so if you want to install it and write up your
experiences on the wiki (or just in a blog post we can link to!), that's
a great place to start!
Thanks for taking care of these (as always!). I have one quick comment.
On Apr 26, 2011, at 01:00 AM, noreply(a)launchpad.net wrote:
>committer: Mark Sapiro <msapiro(a)value.net>
>branch nick: 2.1
>timestamp: Mon 2011-04-25 16:52:35 -0700
> A new list poster password has been implemented. This password may only
> be used in Approved: or X-Approved: headers for pre-approving posts.
> Using this password for that purpose precludes compromise of a more
> valuable password sent in plain text email. Bug #770581.
=== modified file 'Mailman/Defaults.py.in'
--- Mailman/Defaults.py.in 2011-04-25 22:40:16 +0000
+++ Mailman/Defaults.py.in 2011-04-25 23:52:35 +0000
@@ -1375,6 +1375,11 @@
# option settings
# - List creator, someone who can create and delete lists, but cannot
# (necessarily) configure the list.
+# - List poster, someone who can pre-approve her/his own posts to the list by
+# including an Approved: or X-Approved: header or first body line pseudo-
+# header containing the poster password. The list admin and moderator
+# passwords can also be used for this purpose, but the poster password can
+# only be used for this and nothing else.
# - List moderator, someone who can tend to pending requests such as
# subscription requests, or held messages
# - List administrator, someone who has total control over a list, can
@@ -1389,7 +1394,8 @@
AuthCreator = 2 # List Creator / Destroyer
AuthListAdmin = 3 # List Administrator (total control over list)
AuthListModerator = 4 # List Moderator (can only handle held requests)
-AuthSiteAdmin = 5 # Site Administrator (total control over everything)
+AuthListPoster = 5 # List poster (Approved: <pw> header in posts only)
+AuthSiteAdmin = 6 # Site Administrator (total control over everything)
While this is probably harmless, it does make me nervous. I'd probably have
added the AuthListPoster as value 6 and left AuthSiteAdmin as 5. It's
unlikely that someone has squirreled these values away, but if they have,
this might break their code because their AuthSiteAdmin enum value is now
I'll leave it up to you, but please consider changing AuthSiteAdmin back to 5
and adding AuthListPoster as 6.
This is Mailman 2.14, but the bug was also present in ancient releases.
We have a list configured like this:
The global settings are:
Even though no html archives are being generated, Mailman still creates
the attachments directory for this list, and saves all attachments in
I've traced the code responsible for this to ArchiverMailbox.__init__(),
invoked by HyperArchive.processUnixMailbox(). I couldn't find where
Mailman uses the perl-list 'archive' flag. Only the global
DEFAULT_ARCHIVE seems to be considered.
Systems Administrator, Free Software Foundation
I am a gsoc participant and here is my project proposal
As a first step, I have gone through all the use cases of archives UI
listed as part of Systers Archive Project
and these are my views. Please give your feedback.
Users Viewing a Conversation
1.Users want to be able to navigate all messages within a
conversation in as few clicks as possible
2.Users prefer spending less time browsing all messages in a
3.Suppose the conversation the user found is a question about
solving a technical problem. Users would want to be able to easily find
replies (answers) to the original message.
-> Very important use cases. Even if we don't have any notion of a
'conversation', showing more than one message on a page will help users
to quickly browse through all the messages in a thread.
Handling Top/Bottom Posting
/By default, the quoted text can either be all hidden or all displayed.
It might also be good to only hide the quoted text when it is at the end
of the message, as when it is in the middle, the user is likely to want
to see it for context.
->On mailing lists, people generally use 'inline posting' to reply. One
level of inline posting is helpful to see the context, but if it goes
beyond one level then, it might be a good idea to hide the old quoted text.
Users Viewing Index of Conversations
Single Archive and Page-Splitting for Conversations Index - 2010-07-09,
->This is a good idea to view archives as a conversation.
Users Viewing a Conversation
4.Users want to be able to easily separate the meta data (sender's
name, date the message was sent etc) from the post so they can either
skip over or really pay attention to whichever part they need.
5.Some users may want to be able to distinguish between replying to
the sender and replying to the mailing list
Situations that involve filtering messages by date:
-> Though, it is very easy to implement.
Support for Non-dlist lists:
-> I don't have much idea how many users use this.
*One more Use case*
When a user views a message, he is provided the link to either go to
previous message or next message. Along with those links, we can show a
list of links to all messages of that thread along with author names, to
allow that user to directly jump to any message in that thread.
"Mail-archive" provides this feature.
Looking forward to your comments.
Hello, my name is Andrew Rodman and I'm a college student looking to get
involved in your Mailman mailing list manager through Google's Summer of
Code. This is my first year investigating the program and I'm unsure about
the steps I need to take to apply for this project. I'm assuming I need to
write a project proposal but I'm not entirely sure where to start my
research for this application. Would you mind pointing me in the right